Yeah, I can reproduce this almost reliably.  Nautilus crashes when I try to open
the Trash folder.

It's not a crash, it's an assertion failure.

#6  0x40f3e8e1 in g_assert_warning () from /opt/gnome/lib/libglib-2.0.so.0
No symbol table info available.
#7  0x413b350f in find_trash_in_hierarchy (
    start_dir=0x82145a8 "/media/CANON_DC", near_device_id=19, 
    context=0x8199288) at file-method.c:1372
	trash_path = 0x82170b0 "/media/CANON_DC/.Trash-federico"
	stat_buffer = {st_dev = 2065, __pad1 = 0, __st_ino = 1126, 
  st_mode = 16877, st_nlink = 2, st_uid = 1000, st_gid = 100, st_rdev = 0, 
  __pad2 = 0, st_size = 4096, st_blksize = 4096, st_blocks = 8, st_atim = {
    tv_sec = 1125527098, tv_nsec = 0}, st_mtim = {tv_sec = 1125527098, 
    tv_nsec = 0}, st_ctim = {tv_sec = 1125527098, tv_nsec = 0}, st_ino = 1126}
	__PRETTY_FUNCTION__ = "find_trash_in_hierarchy"
#8  0x413b3ef9 in find_or_create_trash_near (
    full_name_near=0x8214c08 "/media/CANON_DC", near_device_id=19, 
    create_if_needed=0, find_if_needed=1, permissions=448, context=0x8199288)
    at file-method.c:1789
	result = 0x0
	disk_top_directory = 0x82145a8 "/media/CANON_DC"
#9  0x413b4082 in find_trash_directory (
    full_name_near=0x8214c08 "/media/CANON_DC", near_device_id=19, 
    create_if_needed=0, find_if_needed=1, permissions=448, context=0x8199288)
    at file-method.c:1851
	result = 0x0

The assertion in frame 6 reads g_assert (near_device_id == stat_buffer.st_dev)

That is, gnome-vfs asserts that it didn't screw up something while finding the
trash directory, and that the directory it found
(/media/CANON_DC/.Trash-federico) is in the same device as the device on which
it is trying to find the trash (/media/CANON_DC).

Note that near_device_id = 19 = 0x013 (that's the requested device).  However,
note that stat_buffer.st_dev = 2065 = 0x811.

0x013 means device major 0 (???), device minor 0x13.

0x811 means device major 8 (SCSI), device minor 0x11.  This makes sense, since
my multi-card reader gets represented as a multi-LUN scsi device.

I ran this while inserting my compactflash card:

  while true; do stat /media/CANON_DC >> /tmp/stats; done

Before I insert the card, that path of course doesn't exist.  After I insert it:

1. /media/CANON_DC appears with the same st_dev as my / - this makes sense, as
the directory was just created.

2. Then it changes its device number to 0x13 - I don't know why this happens. 
Does submount set that device number?

3. Then it changes again to 0x811, which is the proper "partition" in /dev/sda.

I'll read the gnome-vfs submount patch carefully to see if one must use special
code to handle submount.

Also, and this is more worrysome - the mount in its final state has different
device numbers for the mount point and the files inside the mount.  That is,
st_dev is different for /media/CANON_DC and /media/CANON_DC/randomfile.txt.  If
this *is* submount's fault, it could break a lot of software.

Looking at my /tmp/stats log file more closely, the sequence is this

1. /media/CANON_DC appears with st_dev = st_dev(/)
2. it changes st_dev to 0x13
3. it changes st_dev to 0x811
4. it changes *again* back to 0x13

The effect on gnome-vfs is a race condition between (2) and (3).

I just filed bug #114875 against the kernel/subfs.

See comment 2 in bug #114875; that describes the problem in detail.

A very, very ugly workaround is perhaps to open() the full_name_near in
libgnomevfs/file-method.c:do_find_directory(), before doing the stat(), so that
the volume will be really mounted in the kernel --- thus, we'll get the right
device number, not what subfs uses for "not-really-mounted" mount points.

I'd rather have this fixed in subfs.  We just can't kludge every piece of
software for which subfs breaks Unix semantics.

Created attachment 48653 [details]
gnome-vfs2-114473-ensure-mounted-subfs-volume.diff

I'll use this patch.  It holds an opendir() around the call that stat()s the
mount point.  It works for me.

Hmm, macintyre is not letting me log in, so I can't submit this patch to
Autobuild.  I'll try again on Monday.

Gary, JP said that I could assign this to you, as you'd be pulling in GNOME
2.12.   Could you please add the patch in comment #7 to gnome-vfs2?  Thanks :)

Patch submitted for RC1.