After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 139854 - 'mount --bind' causes wrong thing to appear in place of 'Filesystem'
'mount --bind' causes wrong thing to appear in place of 'Filesystem'
Product: gnome-vfs
Classification: Deprecated
Component: Other
cvs (head)
Other Linux
: High major
: ---
Assigned To: gnome-vfs maintainers
gnome-vfs maintainers
: 140320 145337 (view as bug list)
Depends on:
Reported: 2004-04-12 23:40 UTC by Simon Watson
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: 2.8.0
GNOME version: 2.7/2.8

Fix for GnomeVFS (1.09 KB, patch)
2004-04-22 17:46 UTC, Josselin Mouette
none Details | Review
the fix (744 bytes, patch)
2004-07-31 16:44 UTC, Danielle Madeley
none Details | Review
fixes Trash as well (1.22 KB, patch)
2004-08-22 04:09 UTC, Danielle Madeley
none Details | Review

Description Simon Watson 2004-04-12 23:40:17 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
Comment 1 Federico Mena Quintero 2004-04-14 16:39:28 UTC
I don't have udev to test this, but this is most likely a problem with the
gnome-vfs backend in libtgnomeui.
Comment 2 Phil Stewart 2004-04-17 21:35:34 UTC
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 :-)
Comment 3 Phil Stewart 2004-04-18 11:26:15 UTC
Turns out the /dev/root behaviour in /rpoc/mounts is expected. See:

Looks like /proc/mounts just needs handling with care ...
Comment 4 Simon Watson 2004-04-18 12:17:16 UTC
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 ?
Comment 5 Federico Mena Quintero 2004-04-19 19:44:02 UTC
*** Bug 140320 has been marked as a duplicate of this bug. ***
Comment 6 Federico Mena Quintero 2004-04-19 23:20:06 UTC
Retitling for clarity.
Comment 7 Josselin Mouette 2004-04-22 17:46:43 UTC
Created attachment 26977 [details] [review]
Fix for GnomeVFS

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.
Comment 8 Anders Carlsson 2004-05-02 10:42:47 UTC
Moving to gnome-vfs
Comment 9 Alexander Larsson 2004-05-04 13:37:55 UTC
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.
Comment 10 Danielle Madeley 2004-05-11 10:24:39 UTC
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.
Comment 11 Danielle Madeley 2004-05-15 09:29:35 UTC
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

This bug should be retitled to being a glitch with "mount --bind" as well as
being a problem in both gtk+ and gnome-vfs.
Comment 12 Danielle Madeley 2004-07-24 13:51:52 UTC
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.
Comment 13 Paolo Maggi 2004-07-26 14:40:48 UTC
*** Bug 145337 has been marked as a duplicate of this bug. ***
Comment 14 Danielle Madeley 2004-07-31 16:44:38 UTC
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

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).
Comment 15 Ian Laurie 2004-08-08 01:01:51 UTC
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?
Comment 16 Danielle Madeley 2004-08-08 02:39:12 UTC
1.0.5? I'm working against 2.7.x. Ensure you are using the right -p level to patch.
Comment 17 Ian Laurie 2004-08-08 03:01:58 UTC
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.
Comment 18 Danielle Madeley 2004-08-08 03:09:34 UTC
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.
Comment 19 Ian Laurie 2004-08-08 11:39:57 UTC
OK thanks, patch implemented in gnome-vfs2.  It works.

However, my trash can no longer works.  Did this patch also stop your trash from
Comment 20 Danielle Madeley 2004-08-08 13:25:06 UTC
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.
Comment 21 Ian Laurie 2004-08-10 08:40:26 UTC
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.
Comment 22 Danielle Madeley 2004-08-11 13:31:08 UTC
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.
Comment 23 Andrew Sobala 2004-08-21 10:18:10 UTC
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.
Comment 24 Danielle Madeley 2004-08-22 04:09:17 UTC
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.
Comment 25 Ian Laurie 2004-08-22 06:14:51 UTC
Works for me.  I've posted some source and binary RPMs here:

to make life easier for others to try it out.
Comment 26 Alexander Larsson 2004-08-24 15:11:47 UTC
There is a patch in cvs now that should fix this. Could you please try it?

2004-08-24  Alexander Larsson  <>

	* libgnomevfs/gnome-vfs-unix-mounts.c (_gnome_vfs_get_current_unix_mounts):
	Workaround for --bind mounts. Patch from Davyd Madeley <>
	Fixes bug #139854
Comment 27 Danielle Madeley 2004-08-31 02:14:48 UTC
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).
Comment 28 Alexander Larsson 2004-08-31 06:45:40 UTC
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.
Comment 29 Danielle Madeley 2004-08-31 06:59:52 UTC
Well, yes, but that's all because it's new. I was more indicating it will solve
the problem eventually.