GNOME Bugzilla – Bug 139854
'mount --bind' causes wrong thing to appear in place of 'Filesystem'
Last modified: 2004-12-22 21:47:04 UTC
Unsure. Appeaars to be related to udev - but I cannot be 100%. Basically, I have an extra ".dev" entry, which shouldn't be there - and no Filesystem item in my bookmarks list on the file selector. For an example, see http://swat.me.uk/filesel.png
I don't have udev to test this, but this is most likely a problem with the gnome-vfs backend in libtgnomeui.
This is a problem with /dev/root in /proc/mounts - on my router box (normal /dev, Debian Stable, 2.2 kernel) /proc/mounts has one line concerning /dev/root: /dev/root / ext2 rw 0 0 On my workstation (udev /dev, Debian Unstable/Experimental, 2.6.5 kernel), /proc/mounts shows two lines: /dev/root / ext2 rw 0 0 /dev/root /etc/udev/.dev ext2 rw 0 0 It looks like the file selector is picking up this second entry, whereas Nautilus works normally, presumably using the first entry. The full /proc/mounts breakdown looks like this: rootfs / rootfs rw 0 0 /dev/root / ext2 rw 0 0 proc /proc proc rw 0 0 <-- mounted by /etc/init.d/mountvirtfs sysfs /sys sysfs rw 0 0 <-- ditto usbfs /proc/bus/usb usbfs rw 0 0 /dev/root /etc/udev/.dev ext2 rw 0 0 <-- mounted by /etc/init.d/udev none /dev tmpfs rw 0 0 <-- ditto devpts /dev/pts devpts rw 0 0 <-- /dev/pts remounted under the new /dev tmpfs /dev/shm tmpfs rw 0 0 /dev/hda7 /data ext2 rw 0 0 tmpfs /tmp/jack tmpfs rw 0 0 What /etc/init.d/udev (apparently) does when starting udev is to bind /dev to /etc/udev/.dev, mount tmpfs on top of /dev, then start udev. /etc/udev/.dev appears to be a bog standard complete dev directory, so I assume the bind mount is to provide a functioning dev while the next mount command is operating. However, the script doesn't go to plan: /etc/init.d/udev actually gets bound to /dev/root. By the looks of it, bash (2.05b.0(1)-release) has an issue resolving the $udev_root variable (which in the script should resolve as /dev/). When I hard code the variable out in the bind mount, the script behaves as expected, the spurious /dev/root line in /proc/mounts is replaced by the correct bind mount line, and File Selector identifies 'Filesystem' correctly. Evidently, the root cause of the problem is this failure in the udev init script (for which I will generate separate bug report(s) as appropriate), however it usefully identified this fun gnome bug, which may otherwise have gone by unnoticed, as presumably any sensible system won't have multiple /dev/root mounts :-)
Turns out the /dev/root behaviour in /rpoc/mounts is expected. See: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=244398 Looks like /proc/mounts just needs handling with care ...
A small maybe unrelated point, my /proc/mount: rootfs / rootfs rw 0 0 /dev2/root2 / reiserfs rw 0 0 proc /proc proc rw 0 0 sysfs /sys sysfs rw 0 0 /dev2/root2 /etc/udev/.dev reiserfs rw 0 0 none /dev tmpfs rw 0 0 devpts /dev/pts devpts rw 0 0 tmpfs /dev/shm tmpfs rw 0 0 /dev/hda2 /boot ext3 rw 0 0 /dev/hda7 /home reiserfs rw 0 0 /dev/hdg1 /data reiserfs rw 0 0 usbfs /proc/bus/usb usbfs rw 0 0 none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0 Is there any additional problem caused by /dev2/root2 ?
*** Bug 140320 has been marked as a duplicate of this bug. ***
Retitling for clarity.
Created attachment 26977 [details] [review] Fix for GnomeVFS 2.6.1.1 This is caused by gnome_vfs_volume_monitor_get_volume_for_path which doesn't make a difference between bind mounts and real mounts. The attached patch fixes this by testing the URI of the mount is actually a parent of the URI we are looking for. The bug should be reassigned to gnome-vfs imho.
Moving to gnome-vfs
That patch isn't right. Symlinks and things like that means you can't just look at the pathname to figure out which mount a file is on.
Ok, looking into what's going on here. As far as I can tell: This bug isn't specific to udev, it's in fact a problem with the use of `mount --bind` which udev uses. To replicate, try `mount --bind $somedir $someotherdir` this should make the contents of $somedir appear in $someotherdir, it will also place an entry in /proc/mounts similar to: /dev/root /mnt/other ext3 rw 0 0 Now in my example (using `mount --bind /home/b /mnt/other`), instead of having a '.dev' directory in place of Filesystem, I now have a 'other' directory. See http://davyd.angrygoats.net/images/gtkfilechooser-messed-up-mount-bind.png
Thinking further, this is a two pronged bug. It seems to exist in both GtkFileSystem (which is what we've seen so far) and in gnome-vfs (see http://davyd.angrygoats.net/images/filechooser-mount-bind-broken.png). This bug should be retitled to being a glitch with "mount --bind" as well as being a problem in both gtk+ and gnome-vfs.
Renaming this bug to indicate it's really a bug with 'mount --bind' I also realised it doesn't exist in GtkFileSystem, I'm just on crack. So it's only in gnome-vfs.
*** Bug 145337 has been marked as a duplicate of this bug. ***
Created attachment 30112 [details] [review] the fix This fixes it, the problem was thus: gnome-vfs was looking up '/' by stat-ing it and comparing it's st_dev to the list of other st_dev's. Both the a filesystem and any filesystems mount-binded inside it will have the same st_dev, gnome-vfs was picking the first one in the list. Removing /dev/root entries from the list of entries we can enumerate through should solve this problem, without removing any functionality (we don't use /dev/root to glean any useful information).
I am trying to apply your patch to gnome-vfs-1.0.5-18 in FC2 but the file you reference in the patch doesn't seem to be in gnome-vfs-1.0.5-18. Do you happen to know where that bit of code lies in my version?
1.0.5? I'm working against 2.7.x. Ensure you are using the right -p level to patch.
Under FC2 GNOME is 2.6.0 which uses gnome-vfs-1.0.5-18. I don't have the file gnome-vfs-unix-mounts.c in my version. Command: find . -name "gnome-vfs-unix*" yields nothing. I've tried grepping around too looking for code but no luck with string matching. I've looked manually also but can't find the file that does it.
I think you'll find you want to look in gnome-vfs2-2.6.0-8. The other package will be gnome-vfs from 1.4. Kept their for compatibility reasons.
OK thanks, patch implemented in gnome-vfs2. It works. However, my trash can no longer works. Did this patch also stop your trash from working?
Hmm, my Trash doesn't work. I hadn't noticed because I never use it. This bug may be because of my patch, but I don't immediately see how.
I folded back to my pre-patched gnome-vfs2 in case there were side effects beysides the Trash not working. When I logged back in the Trash had stuff in it.... absolutely everything I deleted since installing the patch! So be careful... you may be ammassing a lot of stuff in the Trash without realizing it.
I had a look into this and noticed that ~/.Trash was being filled as expected, so it's definitely not an issue with Trash working, rather an issue with showing the Trash.
Only tentatively a 2.8.0 issue - would be really nice to have in by GNOME 2.8.0 final, but I'm ready to punt it off the milestone.
Created attachment 30823 [details] [review] fixes Trash as well I couldn't see why the trash wouldn't be working with the first patch, I must be missing something. However this updated patch allows it to work by only removing references to /dev/root that aren't for the / drive. This doesn't strike me as the neatest way to do it, however since this part of the code is unix specific (and even Linux specific as nothing else has /proc), this should be acceptable.
Works for me. I've posted some source and binary RPMs here: http://www.zipworld.com.au/~iml/ to make life easier for others to try it out.
There is a patch in cvs now that should fix this. Could you please try it? 2004-08-24 Alexander Larsson <alexl@redhat.com> * libgnomevfs/gnome-vfs-unix-mounts.c (_gnome_vfs_get_current_unix_mounts): Workaround for --bind mounts. Patch from Davyd Madeley <davyd@madeley.id.au> Fixes bug #139854
This seems to be working fine. It should be noted, this bug does not appear with HAL enabled gnome-vfs (we are using gnome-vfs-hal-mounts, rather than g-v-unix-mounts). This means that in the future, this hack will become unrequired on all HAL enabled machines (hopefully all of them).
The HAL gnome-vfs volume backend has some serious issues though. It doesn't report all mounted filesystems as volumes, so things like trash and some nautilus volume handling stuff will break.
Well, yes, but that's all because it's new. I was more indicating it will solve the problem eventually.