Confirming in nautilus in preview4. Exactly - file is properly moved to
~/.Trash, but it is not displayed. It causes bad user experinece - setting to major.

What version of nautilus is in preview4? Because this is broken also for me in
2.11.4, but works great from CVS (2.11.91)

nautilus-2.11.4. 2.11.90 is waiting for submission.

Its been submitted.

beta1 has 2.11.90 but still shows this bug.

Same problem with moving files to trash from gthumb.

It's already reported upstream: http://bugzilla.gnome.org/show_bug.cgi?id=171073

*** Bug 105726 has been marked as a duplicate of this bug. ***

This seems to work on CVS HEAD, so I guess we need an update to nautilus 2.11.92
and gnome-vfs 2.11.91

I just tested this as built from CVS, and indeed it works.

With nautilus and gnome-vfs2 2.11.92 from beta3, it *doesn't* work.

SuSE has something different from a stock build that makes the trash not work there.

Our gnome-vfs2 package has a patch which tries to dlopen fam or gamin depending
on which one is installed.  I tried removing that patch, but things still don't
work.

I'll start tracing the Nautilus trash code to see what's going on.

Hmmm, we hit this point when Nautilus is initializing:

nautilus_trash_directory_finish_initializing() {
  volumes = gnome_vfs_volume_monitor_get_mounted_volumes();
  foreach (v in volumes) {
    if (!gnome_vfs_volume_monitor_handles_trash (v))
       /* do nothing */
    else
       add_volume_to_list_of_trash_volumes (v);
  }
}

With a GNOME session out of CVS, gnome_vfs_volume_monitor_get_mounted_volumes()
gives me all my mounts, including /home and a special /archive I have.

With Suse 10, however, I get *no* "normal" partitions - no /home, no /archive.

With CVS, I get two volumes with volume->priv->activation_uri="file:///":  one
with volume->priv->filesystem_type="rootfs", and another one with
volume->priv->filesystem_type="ext3".  The "ext3" one gets picked up as "yes, it
can handle trash".

With Suse 10, I only get a single volume with
volume->priv->activation_uri="file:///", and it has filesystem_type="rootfs". 
For that file system type, gnome-vfs decides that it can't handle trash.

Now I wonder why the lists of mounted volumes are different on CVS and on Suse.

During the initialization of gnome-vfs-daemon, first it initializes HAL.  Then
it calls update_mtab_volumes().  This is what removes based on the result of
_gnome_vfs_hal_mounts_modify_volume().  I don't know if that's normal or not -
that function and the HAL stuff that it calls are quite convoluted.

It "works" on a CVS build because jhbuild by default installs things
incorrectly, and gnome-vfs2 can't contact D-BUS and thus HAL.  When that
happens, it falls back to FAM-based monitoring to figure out the list of mounts.
 That's why trash appears to work there.

The basic problem is that when gnome-vfs-daemon starts up, it doesn't ever call
_gnome_vfs_volume_monitor_mounted() for the volumes which represent my
partitions.  That function puts the volume in the list of volumes which will be
then sent to client programs.

At that stage, that function can get called like this:

  gnome_vfs_volume_monitor_daemon_init()
    _gnome_vfs_hal_mounts_init()
      _hal_update_all()
        _hal_add_volume()
          _gnome_vfs_volume_monitor_mounted() <----- here
    update_mtab_volumes()
      _gnome_vfs_volume_monitor_mounted()     <----- here

In the first case, hal doesn't even pick up the volumes for the partitions.

In the second case, the partitions get picked up from mtab, but are *not* added
as volumes since gnome-vfs cannot find their UDIs among the drives.

I don't know if the first case is behaving normally... I need to ask David Zeuthen.

OK, I mailed gnome-vfs-list about this.

See bug #113005; this mentions the gnome-vfs code that fetches stuff from HAL.

As far as I can tell, it is normal for _hal_update_all() not to insert the
partition for "/home" - it is even special-cased.

Now I'm tracking down the other part inside update_mtab_volumes().

*** Bug 113952 has been marked as a duplicate of this bug. ***

I'm making this bug visible to the public.

DavidZ says he may have a patch for this tomorrow morning.

The problem is that drives and volumes in local partitions end up not being in
GnomeVFSVolumeMonitor's master lists.  They need to be there, and be flagged
with user_visible=FALSE.  Getting the code to do that is a bit tricky.

A super-quick hack that makes Trash work again is to stick a "return TRUE;" at
the beginning of both _hal_drive_policy_check() and _hal_volume_policy_check().
 This has the ugly effect of making computer:/// show a lot of unwanted stuff.

Would it be reasonable to expect this to be fixed in Beta 4?

It's not fixed in beta4, which comes out today :)

Patience, my friend.  Soon the rebellion will be crushed and

Errr, I mean, David Zeuthen and I have a good handle on this already, so it's
likely that we'll have a fix this week.

LOL! I know you said Beta 4 is out today ahead of schedule, but where is it?
Also, do I have to get all the cds downloaded and install again or will I be
able to do a YAST update?

See opensuse.org for update info.

OK, package submitted to autobuild.  The fix will appear in gnome-vfs2-2.11.92-4
or later.