From: Jeffrey L. <la...@re...> - 2007-07-24 19:18:34
|
On Fri, 2007-07-20 at 13:36 +0200, Goswin von Brederlow wrote: > If openat() is used then you could do a little trick. On the read-only > / you add a symlink to /proc/mounts (so fusermounts does not edit > mtab) and on the read-write you add an actual /etc/mtab after the > mount. That way user mounts and loopback will work after bootup. A number of things don't work when /etc/mtab links to /proc/mounts, even if it's just for the r/o part of the root filesystem. It's not really an option. -n would solve the problem nicely, especially if we also have an option to update mtab without actually doing the mount so that we can make /etc/mtab consistent after-the-fact. This also brings FUSE into line with other mount utilities which have traditionally supplied these capabilities. Another option we could use would be to disable mucking with /etc/mtab if the initial lock attempt fails. I consider this the least desirable option. A third option would be to not muck with /etc/mtab if /etc/mtab is a child of the target mountpoint. This has the advantage of having fusermount do something sensible rather than hanging -- this is probably a good idea even if we add -n. Jeff |