Trash always empty.

[Étienne BERSAC]

Hello,

Event if $HOME/.Trash is full, trash: display an empty folder. And user is not able to "empty trash".

Thanks.

[Étienne BERSAC (bersace)]

Addendum:

Wish this is the right component to file this bug.

[delaney (dfearon)]

I am having this problem too.. have posted in the forums here -> http://www.ubuntuforums.org/showthread.php?p=811629#post811629

and have been seeing other users report the same problem..

[Mike Sylvester (psyberonezero)]

I have the same issue, ls ~/.Trash lists around 40 items yet clicking on trash I get an empty folder and Emty Trash isn't available from the context menu

[jon_gunnar (jonrue)]

This bug showed up yesterday 13.03 for me. Trash always display as containing files,if I open it with nautilus there is a collection of items,all of them with sewerly garbled names.Not possible to empty trash by right clicking,then it just hangs until I kills the window.

If opening ~/.Trash with mc and show all files,the folder show up empty.

Running a fully updated amd64 sytem.

[Bil-E-daKid (heydonkey)]

Can confirm this is occuring in dapper for me too. Using 2.6.15-18-686 kernel and 2.14.0 GNOME.

[Étienne BERSAC (bersace)]

Hello,

Strange, but on a fresh install via espresso, i do not have that bug ...

So this can be a mis configuration bug or .... don't know.

Étienne.

[delaney (dfearon)]

This is not due to misconfiguration as Etienne has attempted to suggest. I have done a clean install from the FLIGHT 5 iso TWICE now in an attempt to rectify this problem and both times have been greated with the bug from the start. Before adding any additional codecs or software.. and as the very first thing i attempt from the very first login.. this bug is present on my pc.

Surely there must be some indication of what is going on? With the amount of attention this is getting here and on the forums.. this could at least have been "confirmed" by now?

Perhaps i dont understand the process..

[Étienne BERSAC (bersace)]

Hello,

> This is not due to misconfiguration as Etienne has attempted to
> suggest.
> I have done a clean install from the FLIGHT 5 iso TWICE now in an
> attempt to rectify this problem and both times have been greated with
> the bug from the start. Before adding any additional codecs or
> software.. and as the very first thing i attempt from the very first
> login.. this bug is present on my pc.
Yes, you're right. I also remove all my ~/.* and the bug still occurs.

Étienne.

[peter (peter-campbell)]

I have this issue also.

I discovered yesterday that the trash applet and desktop icon reflect the status of the .Trash folder on my usb stick even when the stick is not present. Reboot does not revert the settings to reflect the status of ~/.Trash

[Daniel Holbach (dholbach)]

This has nothing to do with libtrash, reassigning.

[Sebastien Bacher (seb128)]

Thanks for your bug. Do you use the nautilus trash or the panel trash applet? What filesystem are you using? How did you deletes the files to the trash?

[Joolz (joolz)]

I have the opposite problem. Trash applet 2.12.1 on Breezy shows a "full icon" and "2 items in Trash" tooltip even though it's empty. Rightclick and empty trash doesn't help. ls -al ~/.Trash or nautilus show no contents apart from . and ..

Removing and putting back the applet solves the issue. This is NOT a hard problem, sometimes the thrash applet will correctly show that it's empty.

[Sebastien Bacher (seb128)]

not a libtrash issue

[David M. Carney (carney1979)]

Having the same problem on a fresh Dapper Flight install (AMD64).

Applet is always empty, even after deleting items. NOTE: Delete command that bypasses wastebasket is NOT enabled here.

If I use Nautilus to go to ~/.Trash, the items previously deleted are there, though the trash applet does not indicate anything is in the trash. If I double-click on the applet, a Nautilus window with "Wastebasket" in the location bar appears; it's usually empty (see below).

If I plug in my USB jump drive, it is auto mounted. If I delete something on it, a hidden folder is created called .Trash-david (david is my username) and the deleted items go there.

My trash applet still shows empty, but if I double-click on it, then a Nautilus window opens showing me the .Trash-david folder contents.

Why my USB jump drive even needs a trash folder is beyond me.

So how do I get my Trash applet to "point" back to my ~/.Trash folder and to display trash correctly? Is there a config file somewhere that does this?

David

[David M. Carney (carney1979)]

The above first line was supposed to read "Dapper Flight 5".

Sorry!

David

[David M. Carney (carney1979)]

This was found on a blogger's site. She seems to indicate a very familar problem with Gnome's trash in NetBSD.

Web site is:

http://julipedia.blogspot.com/

Relevant text is:

 Fixing GNOME's trash under NetBSD

For a very long long time (probably since forever), the trash icon in GNOME has not worked in NetBSD. You'd drag files onto it and they were appropriately deleted but, unfortunately, the trash did not update its status to reflect the removed files. If you opened the folder, it appeared empty despite ~/.Trash contained the deleted files. As you can image this was very annoying as it made the trash near to useless.

However, and by pure luck, some days ago I noticed that the trash icon showed some files on my machine. For a moment I thought that the problem had been fixed with GNOME 2.14.0. But I was wrong: ~/.Trash didn't contain the files shown in the trash window; the files were really stored in /vol/data/.Trash-jmmv. So why was it picking up the files from one directory but not from the other one?

I started by looking for the .Trash string in gnome-vfs which led me to a piece of code that returns the trash directory for a given volume. I first thought that there could be a problem detecting the home directory so I added some debugging messages there; everything looked correctly.

After digging some more and thanks to the test/test-volume test utility, I ended up in the libgnomevfs/gnome-vfs-filesystem-type.c file. This contains a table called fs_data that maps each file system name to a description and to a boolean. The boolean indicates whether the file system is supposed to hold a trash or not. As you can imagine, ffs was not part of this list, so the code felt back to the default values that specify that there was no trash.

Solving the issue was trivial. I just had to add the appropriate file system names to the table, rebuild gnome-vfs and experience the trash icon to its full power :-) The issue is reported in bug #336533 and is already commited to pkgsrc. Therefore, it will be part of the forthcoming pkgsrc-2006Q1 stable branch.

[David M. Carney (carney1979)]

<snip>

Do you use the nautilus trash or the panel trash applet?

<unsnip>

Panel trash applet

<snip>

What filesystem are you using?

<unsnip>

ext3 - Ubuntu default

<snip>

How did you deletes the files to the trash?

<unsnip>

Mainly used right-click >> Move to Trash on a file.

Also tried dragging file to trash applet on panel with no apparent change in the results.

David

[peter (peter-campbell)]

I had this exact same problem, filed it here: https://launchpad.net/distros/ubuntu/+source/gnome-applets/+bug/35834
and it went away on March 27.

In case it's of any help:
I used both nautilus trash and the panel trash icon: they would show consistent (but erroneous) in formation.
I mostly deleted stuff with the delete key but right-click>move to trash and drag&drop to trash gave the same results.
I use ext3 fs

[David M. Carney (carney1979)]

Sebastion,

I stumbled onto a personal experience that might help in nailing this down. I can certainly understand how frustrating this can be to solve when you aren't experiencing the same problem yourself.

It all seems to be centered around my USB jump drive.

When an item is deleted from the jump drive, a .Trash folder is created on the jump drive. Right now, my jump drive has items in it's .Trash folder. If I insert my jump drive, as soon as it's automounted, my tash applet is suddenly full. If I click on it, it shows the contents of the .Trash folder on the jump drive.

For some strange reason, when I unmount the jump drive, the applet never changes back to pointing to my ~/.Trash folder. Why we need .Trash on jump drives is beyond me.

Please note that my jump drive is automounted and I always right-click on it and select eject, then wait for the icon to disappear from the desktop before removing it.

Best of luck!

David

[Dani Alonso (dalonso)]

Same beahaviour hear. Surely related to usb storage devices, as many people is reporting.

I have found the following in the nautilus-internals documento hold in gnome cvs:

"7.6 Trash
Nautilus uses the gnome-vfs trash system. It works by creating a trash directory for each
mount point, when it can. The directory is called .Trash-username and stored in the top
directory of the mount. For files on the same device as the user homedir $HOME/.Trash is
used instead."

I believe that the trash gnome vfs code doesn't has a problem. I think the problem is in the trash applet code, as not honouring the several trash paths available in the system.

[Chip Piller (piller)]

The trash applet does not work on the current dapper liveCD (May 19, 2006). See bug #42471.

One can drop items into the trash applet icon and the items go to ~/.Trash, however the trash applet reports that it is empty so one cannot empty the trash.

[datafeilen (datafeilen)]

If you disable DBUS - then the trash can works as normal. I'll guess it has something to do with DBUS then....

[David M. Carney (carney1979)]

datafeilen :

How do you disable DBUS without getting lots of errors in Gnome?

[datafeilen (datafeilen)]

I'm running Ubuntu Dapper and I my point was that if you DO stop the
dbus service - the problem with the empty trashcan icon when deleting
files just disappear. E.G It works just as its supposed to do. I've not
seen any errors from Gnome by doing this,but that said - I've not
scanned the log files for any either. Normally I run the dbus service -
but by pure luck I saw that when I did stop the dbus service, my trash
can seemed to work ok again. When I enable dbus - the problem showed up
again. I've had this problem since I upgraded to Dapper from Breezy.

Another issue is Gnome creating an trash folder on removable disks like
a usb disk or a memory card for a digital camera. It seems like a
really,really bad idea. Hopefully someone working with Gnome
will realize this soon. Spreading trash across multiple folders is NOT a
good practice for a desktop system. Why not use ONE folder for each
user?..

[Sebastien Bacher (seb128)]

The issue with using one trash is that deleting something from a removable media would require to copy it to the local disk which can take some time. Not having a trash on removable medias is bug #12893 and will be fixed

[David M. Carney (carney1979)]

Sebastian: Thanks for the update. With the upcoming Dapper release, you must be **very** busy.

On my Dapper AMD64 Ubuntu system, stopping DBUS (as mentioned above) is not a viable work-around. Too many other things "break". Such as, you can't log out of Gnome without hitting ctrl-alt-backspace.

I also realize it must be maddening to diagnose a problem if you don't have the same problem on your system. I don't envy you.

When bug 12893 is fixed, will that also fix this bug?

If not, and there is ANYTHING I can do to help to fix this, such as test experimental packages, etc, don't hesitate to ask.

David

[David M. Carney (carney1979)]

I see this is still in the "Needs Info" category.

What info does it need?

David

[Sebastien Bacher (seb128)]

it requires somebody not busy with some other hundreds bugs and having the issue looking at it, marking as Unconfirmed

[Federico Del Bene (fdelbene80)]

Had this bug with a clean install of ubuntu 6.06 (final) on (hda0,1).

Actually I have Wastebasket Applet 2.14.1 and GNOME Panel 2.14.1.

.Trash directory is present and fully functional, just not "connected" to the applet.

[Kasper Ronning (kasper-ronning)]

I have this bug too. It's exactly as described above. I've used every version of Ubuntu since Warty, always upgrading the distribution. Stopping DBUS immediately made trash-applet work. Starting DBUS did not make the trash empty again.

[Sebastien Bacher (seb128)]

Confirmed according to the number of duplicates for it

[seguso (maurizio-colucci)]

This might be an important hint.

I have been able to reproduce the bug as follows.

Install edgy. Choose american english in the installation. Use edgy normally for a few days. Delete a file from a partition other than /, so that a folder .Trash-username is created on that partition. Let's call that partition P.

Then, install language support (system -> administration). Install italian language support. Log out and, in gdm, change the language to italian before loggin in. When asked if this should be your default language, choose yes.

Now that you are logged in with the italian language, go to the partition which we called P, and delete a file with nautilus. Then, with nautilus, enter the trashcan (menu -> go -> trash, which in italian is Menu - >Vai -> Cestino). You will notice the trashcan looks empty, instead of containing the deleted file. Now, with nautilus, show hidden files and navigate to the .Trash-username folder. The deleted file does appear there.

So the trashcan bug might be related to localization in some way.

[Sebastien Bacher (seb128)]

there issue is probably due to the other partition rather than the localization

[Robert Lange (rcl24)]

I have identified roughly what happened. I have an LS-120 floppy that was mostly full and I deleted most of the files. (The bug works for pretty much any writable removable media.) At some point, I discovered that the files were not deleted but kept in /mount/point/.Trash-rlange, so I deleted that directory from the command line. (Not yet sure if this action had anything to do with triggering the bug.) Now, the trash: functionality (in both Nautilus and the applet) only appears to work with the floppy media or other removable media. Frankly, I am not sure if it ever worked on my home directory.

I got the build-deps and source for gnomevfs2 and nautilus. I instrumented the function called nautilus_trash_monitor_get_trash_directories(void) in the file libnautilus-private/nautilus-trash-monitor.c so that it would print information to a hard-coded file about the execution of each possible branch in the function's logic. After compiling, installing, and logging out/in, I got no output. In fact, I only get output when I mount a removable device, make a file on the device, delete the file (causing my trash can to activate) and then empty the trash can. Let me restate that this function apparently is only called when the trash can is emptied.

Here are the three possible branches in logic:

1. gnome-vfs reports that trash is not handled by a volume.

2. gnome-vfs reports that trash *could* be handled by a volume, but can't find a suitable place to put it.

3. gnome-vfs reports that trash is handled by a volume and gives a location to put it.

Here is the output of one call to the function:

-----BOF

Entering get_trash_directories...
Found a trash uri: /media/floppy/.Trash-rlange at volume /media/floppy
Did not find a trash uri at volume /var/run
Did not find a trash uri at volume /var/run
Did not find a trash uri at volume /var/lock
Did not find a trash uri at volume /var/lock
Trash reported NOT handled by volume /sys
Trash reported NOT handled by volume /proc/sys/fs/binfmt_misc
Trash reported NOT handled by volume /proc/bus/usb/.usbfs
Did not find a trash uri at volume /proc/bus/usb
Trash reported NOT handled by volume /proc
Did not find a trash uri at volume /lib/modules/2.6.17-10-generic/volatile
Did not find a trash uri at volume /dev/shm
Trash reported NOT handled by volume /dev/pts
Trash reported NOT handled by volume /dev/bus/usb/.usbfs
Did not find a trash uri at volume /dev
Trash reported NOT handled by volume /
Trash reported NOT handled by volume /home/darklord
Trash reported NOT handled by volume /home/rlange
Trash reported NOT handled by volume /home/rlange
Finished get_trash_directories.

-----EOF

I am no nautilus/gnome-vfs expert, but it seems intriguing that (according to the gnome-vfs function gnome_vfs_volume_handles_trash(volume) called by the nautilus function I instrumented) the root and home volumes do not handle trash, and therefore are ignored by the trash: functionality.

So, where do I look next? I am going to instrument the trash finding functions in gnomevfs libgnomevfs/gnome-vfs-volume.c unless anyone has a better idea.

Also, any suggestions about how to run a debugger on nautilus. I tried with ddd and gdb, but nautil...

[Robert Lange (rcl24)]

I have instrumented gnome_vfs_volume_handles_trash(...) in libgnomevfs/gnome-vfs-volume.c. I have observed that gnome-vfs identifies the type of the root filesystem as "rootfs". There is no entry for such a filesystem in gnome-vfs-filesystem-type.c, so it thinks that the root filesytem, on which my home directory exists, does not handle trash. See comment 16 of this thread for another explanation of this.

Could someone explain to me what "rootfs" is any why my root filesystem is not registered as ext3? It was my assumption that the _GnomeVFSVolumePrivate->filesystem_type parameter was supposed to show "ext3" as my file system type.

Absent any insights from you, I will now instrument the code that makes the GnomeVFSVolume structs to find out why my root filesystem is getting mis-read.

Right now I am 99% sure that this is a problem with gnome-vfs not reporting filesystem types correctly. Nautilus seems to be behaving properly given the information gnome-vfs provides.

This problem also seems to be coming back to comment 16 of this thread. However, I disagree about adding a new filesystem type in the table. I want to know why it isn't reporting the correct type to start.

[levmatta (levmatta)]

I also have this problem, it started after I moved my /home folder from one partition to another (I actually moved a lot of things).

[Robert Lange (rcl24)]

I have found some more information, although I don't really have time now to do more.

In the file gnome-vfs-unix-mounts.c there are several different possibilities based on what type of unix you have and how it stores mount information. In particular for Ubuntu the HAVE_MNTENT_H ifdef is used, so the code looks in the file /proc/mounts. The code grabs the first entry for each mountpoint and uses its listed filesystem, even if that isn't the correct listing. This is the comment in the function _gnome_vfs_get_current_unix_mounts:

-----

ignore any mnt_fsname that is repeated and begins with a '/'

We do this to avoid being fooled by --bind mounts, since these have the same device as the location they bind to. Its not an ideal solution to the problem, but its likely that the most important mountpoint is first and the --bind ones after that aren't as important. So it should work.

-----

In this case, the first mount point listing for / has the 'rootfs' filesystem type listed, whereas the second listing has the correct 'ext3' filesystem type. As an experiment, I introduced some code to ignore any entry with a filesystem type of 'rootfs' but this didn't work correctly either.

At this point I won't have time to work on this for a while, but I felt like I should document what I had found here so when I get some time, I can pick up where I left off, or someone else can.

[Sebastien Bacher (seb128)]

Robert, thank you for your work on that. I don't think that the rootfs is an issue, /proc/mounts has a such entry on my box too and the trash works fine. Is your problem with the trash applet or with the nautilus trash or both? Could you describe what you are doing and what is happening exactly?

To debug nautilus you can run "gnome-session-remove nautilus" to stop it and then start it from gdb

[Robert Lange (rcl24)]

To reiterate, my problem is that trash does not work for my home directory. The problem is with both the Trash Applet and Nautilus. If I mount a floppy or a USB stick or whatever, trash works correctly for those mounts. However, trash will not work for my home directory.

I have NOT tried deactivating dbus as some other posters suggested. Even if that "works" it would cause so many other problems that I don't consider it a solution.

*****
NOTE: My home directory is a part of the / partition, NOT mounted as a separate partition. If I get some free time, I will do a fresh install on a new machine with /home as its own partition. Based on my observations, I hypothesize that setup would work correctly.
*****

Based on the code I have examined as it was executing, both of those applications are working correctly. Gnome-vfs is feeding them the wrong information.

For example, Nautilus makes a call to determine which mount points must be monitored for garbage and what directory to monitor for each mount point. (libnautilus-private/nautilus-trash-monitor.c: nautilus_trash_monitor_get_trash_directories) This function tells Nautilus that the / partition (and therefore my home directory) does not handle trash. Why? Because it in turn calls (libgnomevfs/gnome-vfs-volume.c: gnome_vfs_volume_handles_trash) for each mount point. This function reports that the / partition does not handle trash. So at this point I think I have proven that the error is in gnome-vfs, not Nautilus.

So why does the (gnome_vfs_volume_handles_trash) function report erroneously? The function gets the filesystem type from the GnomeVFSVolume input data structure and passes it to the function (libgnomevfs/gnome-vfs-filesystem-type.c: _gnome_vfs_filesystem_use_trash) which performs a lookup against a table of known filesystem types. For the / partition the filesystem type is listed as "rootfs" which is not found in the table. Therefore, the function assumes that the / mount must not be able to handle trash.

One kludgy solution would be to add "rootfs" to the lookup table and have it return true. However, this solution would be wrong, as the / partition should not handle user trash anytime the /home directory is mounted in another partition. The only way to find a real solution is to find out why the / mount is listed as "rootfs" rather than as "ext3". To do this, we need to find where the GnomeVFSVolume data structures are being generated. For unix systems, they are generated based on GnomeVFSUnixMount structures, which are generated in libgnomevfs/gnome-vfs-unix-mounts.c. I think in comment 37 I documented the diagnosis pretty clearly, although I still don't have much time to work on it further.

[Robert Lange (rcl24)]

I have just done a fresh install. The only difference between this install and my previous installation is that I have mounted /home on its own partition, as opposed to having only a / partition. Both the Trash applet and Nautilus trash now are able to see and empty trash stored in my ~/.Trash folder.

The bug does seem to be that gnome-vfs sees the / partition as being a "rootfs" filesystem rather than "ext3" or whatever other real filesystem you are actually using.

To prove this theory wrong, someone will have to come forward with a freshly-installed dapper or edgy system, with the /home directory tree belonging to the / mount point rather than a separate mount point, and who does not see this bug.

[Jason Hildebrand (jason-opensky)]

I made a fresh install of dapper in vmware, with /home on a separate partition. I was unable to reproduce the bug.

Then I moved the user's home directory into /, umounted /home and then moved the user's home dir into /home (i.e. not as a separate partition anymore). I was still unable to reproduce the bug.

Here is the output of /proc/mounts (after I umounted /home):
rootfs / rootfs rw 0 0
none /sys sysfs rw 0 0
none /proc proc rw,nodiratime 0 0
udev /dev tmpfs rw 0 0
/dev/sda1 / ext3 rw,data=ordered 0 0
/dev/sda1 /dev/.static/dev ext3 rw,data=ordered 0 0
tmpfs /var/run tmpfs rw 0 0
tmpfs /var/lock tmpfs rw 0 0
tmpfs /lib/modules/2.6.15-26-386/volatile tmpfs rw 0 0
devpts /dev/pts devpts rw 0 0
tmpfs /dev/shm tmpfs rw 0 0
tmpfs /var/run tmpfs rw 0 0
tmpfs /var/lock tmpfs rw 0 0

[Chris Bozic (cbozic)]

I am getting this bug in Feisty.

[agostinomaurotto (agostino-maurotto)]

same here
fresh feisty install and that bug is there

[Chris Bozic (cbozic)]

Yes, I'm still getting it too. Except I've noticed now that the
trash isn't always empty.

I have multiple partitions on my disk. If I delete something from my
/ partition, that shows up in my trash applet. However, if I delete
anything from any other partition, my trash applet is empty and I have
a new hidden trash folder called .Trash-username at the top level of
whatever partition contained my deleted file.

On 4/21/07, agostinomaurotto <email address hidden> wrote:
> same here
> fresh feisty install and that bug is there
>
> --
> Trash always empty.
> https://bugs.launchpad.net/bugs/34247
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Adam Heckler (adamheckler-deactivatedaccount)]

I am having the same problem on Feisty. In this case, a Trash folder was created on my iPod and now the Gnome trash applet is stuck as empty.

[Nick B. (futurepilot)]

I have the same problem. The trash applet shows it's empty and it even says No items in trash. But when I click on it to open the trash there's stuff in it. It seems to be random too, because a few times I actually saw it full.

[hotani (hotani)]

Same problem here on Feisty. My /home is on a separate partition, and I recently had an iPod connected which could have been when the home trash applet got confused.

[dsa (dsa-dontreg)]

Same problem here on fresh install of Feisty. No iPods (or anything else - apart from internal HDD + CD-ROM + DVD-R/W) attached. I have not moved home directory or changed anything else (knowingly) from default settings.

Problem occurs when adding wastebasket icon to lower panel. I've tried removing and re-adding, but no change in behaviour.

[Jake (jake-michaelson)]

I also am experiencing this bug on Feisty (fresh install). I encrypted my home directory with EncFS, following this howto:

http://www.gatorlug.org/node/123

Part of this entails backing up/replacing the home directory. Unfortunately, since I encrypted the home directory soon after my install, I don't know if that had anything to do with me experiencing this bug, or if it was there to begin with.

So still no solution or work-around this? This has been around since at least pre-Dapper.

[Alan Hartless (harty83)]

Also experiencing this on Feisty. Aggravating.

[OpenMindDJ (mrothlein)]

This is happening for me in Ubuntu Feisty - See attached screen shots.

[Mariano Draghi (chaghi)]

I can too confirm this on Feisty.

- Deleted files are moved (correctly) to ~/.Trash on my home partition.
- Tha trash applet is always empty.

I don't understand why this is assigned to gnome-applets. If I navigate to "trash:" with Nautilus, I see the same behavior (directory empyt). Doesn't this have to do with gnome-vfs?

From what I see (and reading most of the comments above) it seems more like a mapping issue between the physical trash folder (f.i., ~/.Trash) and the location to which the URL "trash:" is resolved.

[marwal (marwal)]

I can't empty Trash. The reason is simple. When I select open I go to my root-directory.
Good thing my user doesn't have the right to empty that folder.
How do I point it right?

[Rodrigo Donado (frezeeer)]

Same Problem here, Ubuntu 7.04, trash applet, and trash icon in desktop are empty, even the folder they open when you click in them, but /.Trash is full.

[François Montel (zerohalo)]

I've experienced the same since upgrading to Feisty (I did not have this problem on Edgy).

Files in ~/.Trash do now show up when the Trash applet is launched.

However, files in .Trash under / or any other partition DO show up in the Trash applet. The only ones that don't show up are those in ~/.Trash.

My home folder is in a separate partition encrypted with encfs, meaning it's a FUSE filesystem.

So my guess is that the Trash applet isn't picking up any files that reside on FUSE filesystems.

[François Montel (zerohalo)]

PS. It seems that my problem is already fixed in Gutsy (see https://bugs.launchpad.net/gnome-vfs/+bug/81336). Sorry for the duplicate post. I'm not sure if that fixes the problems other report here or not.

[Tarik Jabri (tjabri)]

This problem is existing right now for me in Gutsy final (running the LiveCD only for now). The applet shows an empty trash while the desktop icon (added manually) shows stuff in the trash. I deleted some items from an external drive, and they show up correctly in Nautilus. I also deleted local files and the trash applet showed no trash. When you right-click on it, it still shows no trash, and there's no way to empty the trash (it's just greyed out). If you right click on the applet and select Open, it does show the trash with stuff in it.

[fish (discordianfish)]

I can confirm that this problem still exists on gutsy final.
System is a iBook / ppc.
When i move a file to trash it will be moved to ~/.Trash correctly but neither a click on the Trash icon in the left bar in nautilus nor a Go->Location->Trash: shows something in the Trash.

[Oleksij Rempel (olerem)]

Same symptoms but this issue for hardy is different. Hardy use new gvfsd and gvfsd-trash... so seems like trashapplet still do not know any thing about it.

[M2G (m2g90)]

It's the same problem in Hardy Heron 8.04 Alpha 4
FIX PLS !!

[tuxalot (darinredding1)]

Having same problem in Hardy. Applet in top bar is working properly however, only desktop icon is amiss.

[aj (aj-xqone-deactivatedaccount)]

Hi...

same problem here (Ubuntu 8.04).
I discovered, that there are 2 different trash locations. The "~/.Trash" directory which is used by (e.g.) gthumb and "trash:///" (~/.local/share/Trash/files) which is used by nautilus.
Only "trash:///" is monitored by the trash applet. This problem is new (to me) since 8.04.

[aj (aj-xqone-deactivatedaccount)]

A possible fix:

symlink the files directory (~/.local/share/Trash/files) to ~/.Trash. This will fix the problem BUT it will also force nautilus to open a window every time you put/delete something to/from trash!

[aj (aj-xqone-deactivatedaccount)]

another note:
it looks like the reason for nautilus to open a new window is simply that it crashes :)

BTW: sorry for all people who gets an email notification for every comment. I promise that this will be my last post for this bug and I am not going to bother you all again...

[wolfwitch (wolf-mylunarden)]

Probably related: The same problem happens in the AVN trash applet. It always shows empty, even when trash is full. Clicking on it opens the appropriate (full) trash folder, but it claims "No Items in Trash".

[Robert Lange (rcl24)]

As of my upgrade to hardy, this bug is fixed for me. Does it still affect anyone who is using hardy, or has this finally been fixed for good?

[Mariano Draghi (chaghi)]

It's solved for me too since Hardy.

There's one detail left, though: The icon of the trash applet doesn't get updated; if I delete something, the applet's tooltip will say that the trash is empty, and the bin will look empty. But if I open it, I can se the delted items. Once you open the Trash in Nautilus the status is updated.

[JoeZ (jrzinskie)]

Ubuntu 7.04 - I show the trash empty, but after installing KDE and Xfce desktops I find that both of them display about 14 GB of content in the Trash. Back to Gnome, I found the files to be in /home/{user}/.local/share/trash/files.

[Sylvain59 (sylvain59)]

Here, on Hardy :

- I can always empty Trash although Trash is empty
- When I delete a file, sometimes the Trash icon shows it empty although there are files in.

[ThomThom (thomas-thomthom)]

Using Hardy upgraded.
Just noticed the icon doesn't update.
If I right-click and view the Properties it reports the number of items in the trash.
If I doubleclick the icon it opens and displays all the items in the trash.
The "Empty Deleted Items" button is disabled.

[FrenchNux (christophe-pauc)]

On hardy :

2 bugs with trash applet :

1 - The icon of the trash applet doesn't get updated.
     if I delete something, the applet's tooltip will say that the trash is empty, and the bin will look empty.
     But if I open it, I can se the delted items. Once you open the Trash in Nautilus the status is updated.

2 - I can always empty Trash although Trash is empty.

[antonioni (antonioni-rocha)]

'Probably related: The same problem happens in the AVN trash applet. It always shows empty, even when trash is full. Clicking on it opens the appropriate (full) trash folder, but it claims "No Items in Trash".'

It occurs sometimes here, too.

[antonioni (antonioni-rocha)]

'On hardy :

2 bugs with trash applet :

1 - The icon of the trash applet doesn't get updated.
     if I delete something, the applet's tooltip will say that the trash is empty, and the bin will look empty.
     But if I open it, I can se the delted items. Once you open the Trash in Nautilus the status is updated.

2 - I can always empty Trash although Trash is empty.'

It occurs sometimes here, too.
Two years that this bug still exists. Aff.

[antonioni (antonioni-rocha)]

Aff. How I use (and distribute to my friends) a system that the trash-applet don't work fine?

This trash-applet is a true swarm of bugs.
I am waiting fix it in Hardy. ¬¬

[antonioni (antonioni-rocha)]

I have found another problem. Sometimes the trash-icon keeps full normally when it has trash. But in the Nautilus window, the button "Empy Trash" becomes disabled (shown in the screenshot).

See it too, please.

[max (maxozilla)]

I can confirm that I am also getting this bug on Ubuntu 8.04.

Steps to reproduce:
- Delete some files

Results:
- Deleted Items Applet on the panel shows an empty trash icon.
- Hovering above the applet gives the tooltip 'No items in the Deleted Items folder'
- When going to trash:/// in Nautilus, all the deleted files are displayed. I can click on the 'Empty Deleted Items' button.

So the deleted items applet is not detecting when the trash has items in it.

[Sebastien Bacher (seb128)]

could be the same issue than bug #72468

[Gonzo (alex-satellite)]

Let me tell you something interesting...
Well, I can confirm I was also getting this bug on Ubuntu 8.04 and, surprisingly, today on Ubuntu 8.10...
I did nothing to misconfigure my system actually. I just install NVidia driver myself using their .run packages from the official site. After installing their latest BETA 180.16 the gnome-panel trash applet stopped showing its actual status (when I delete smth. the icon remains empty, but if I click on it - the deleted stuff is there. Also, the 'Empty trash' link is active.
I decided to uninstall nvidia driver back to previous BETA 180.11 and now it's ok with the trash applet.
Strange?
Yes.

[Sebastien Bacher (seb128)]

could you try if that's still an issue in jaunty?

[Gonzo (alex-satellite)]

Sorry, actually do not want to change to beta :) My system is stable now. Trash applet is working as I told in a previous post: just switched to previous Nvidia driver. Now using the latest stable 180.22 and it's fine.

[Glen (gsawt)]

I can confirm that this bug is still present in Jaunty Beta.

My trash applet is showing items in the trash but there is nothing in there and it is not possible to empty it.

[Oleksij Rempel (olerem)]

it's really strange. I use jaunty beta and never had this problem. Do
you upgrade old system to jaunty? I use fresh install with some of
configs from old system, like for firefox, f-spot, tomboy and thunderbird.

[Gonzo (alex-satellite)]

As for me I've never really upgraded Ubuntu. Fresh install only.
This bug is mysterious. I can use my system for months (without any tweaking) and there will be no bug with the trash applet. And once it is present. A couple of reboots and it's gone again for ages. Don't know what it is.

[Gonzo (alex-satellite)]

Sorry, a little P.S:

The bug is really strange: the icon may show that there are items in the 'actually empty trash' and vice versa.

[Glen (gsawt)]

Yes it seems this bug displays odd behaviour in either direction. It may report trash has items in it when it does not and vice versa.

I upgraded from a nearly stock install of Intrepid so it was a pretty straight forward upgrade even though it is not usually recommended to do so. I haven't found any other issues so far.

[muhalifsirin (alperense)]

I have a similar issue here on Jaunty. i did not have it till yesterday, but today, I got the problem.

When I delete something on my home folder, I can not see them in trash(trash:///), but when I check ~/.local/share/Trash/files I see those deleted files appear there.

This is a really annoying bug,Trash is a simple function that any convenient OS must offer without hassle. It is strange in three years this issue has not been solved and no solution or work around is offered.

[muhalifsirin (alperense)]

Ok, now it is getting worse. Nautilus tells me that my trash folder is empty (not trash:///, which always look empty- I am talking about ~/.local/share/Trash/files)

But then I check it form terminal and I see it is not empty. Moreover bautilus itself tells me that folder is 300 mb(but magically contains no files!!!). This is really driving me crazy now.

[muhalifsirin (alperense)]

So here is I reproduce this bug:

1-Delete an item, (use delete key, drag and drop an item into a trash icon-desktop-applet..etc, or drag and drop the item into an open trash:/// folder ; does not matter)
2- Item disappears
3-But the trash folder still (trash:///) looks empty
4-Search for the deleted item via Places---->Search from the menu
5-You find the item in ~/.local/share/Trash/files (not surprisingly)
6-Check the specified folder using Nautilus, but it looks empty
7-Check it using Terminal, it is not empty. Also Nautilus itself tells you that the folder is not zero bytes, it is 300 mbs(I checked the folder for hidden items as well)

[Oleksij Rempel (olerem)]

I really can't reproduce it. With jaunty i never had this problem.
I use jaunty-amd64 with ext4.

[muhalifsirin (alperense)]

OK

I guess this problem has something to do with mac4lin project (the thing that makes ubuntu look like a mac). I realized i had this problem after I installed that theme. It has this .sh file that automates everything, maybe that was the problem,.

One more weird thing, when gnome-do works in docky mode,the trash app on the dock works OK. But rest is still broken.

I am updating my steps for reproducing the error, and also attaching the .sh file for installing mac theme to ubuntu:

0-Download mac4lin theme package for ubuntu from" http://sourceforge.net/project/downloading.php?group_id=204373&filename=Mac4Lin_v1.0_RC1.tar.gz&a=17712471 "
and run the .sh file to install it
Then proceed as follows to test trash:
1-Delete an item , (use delete key, drag and drop an item into a trash icon-desktop-applet..etc, or drag and drop the item into an open trash:/// folder ; does not matter)
2- Item disappears
3-But the trash folder still (trash:///) looks empty
4-Search for the deleted item via Places---->Search from the menu
5-You find the item in ~/.local/share/Trash/files (not surprisingly)
6-Check the specified folder using Nautilus, but it looks empty
7-Check it using Terminal, it is not empty. Also Nautilus itself tells you that the folder is not zero bytes, it is 300 mbs(I checked the folder for hidden items as well)
8-Gnome-do's trash app works fine in docky mode

[muhalifsirin (alperense)]

OK

I guess this problem has something to do with mac4lin project (the thing that makes ubuntu look like a mac). I realized i had this problem after I installed that theme. It has this .sh file that automates everything, maybe that was the problem,.

One more weird thing, when gnome-do works in docky mode,the trash app on the dock works OK. But rest is still broken.

I am updating my steps for reproducing the error, and also attaching the .sh file for installing mac theme to ubuntu:

0-Download mac4lin theme package for ubuntu from" http://sourceforge.net/project/downloading.php?group_id=204373&filename=Mac4Lin_v1.0_RC1.tar.gz&a=17712471 "
and run the .sh file to install it
Then proceed as follows to test trash:
1-Delete an item , (use delete key, drag and drop an item into a trash icon-desktop-applet..etc, or drag and drop the item into an open trash:/// folder ; does not matter)
2- Item disappears
3-But the trash folder still (trash:///) looks empty
4-Search for the deleted item via Places---->Search from the menu
5-You find the item in ~/.local/share/Trash/files (not surprisingly)
6-Check the specified folder using Nautilus, but it looks empty
7-Check it using Terminal, it is not empty. Also Nautilus itself tells you that the folder is not zero bytes, it is 300 mbs(I checked the folder for hidden items as well)
8-Gnome-do's trash app works fine in docky mode

[muhalifsirin (alperense)]

UPDATE: I don't know how it happened but I got my Trash back!!

[Gonzo (alex-satellite)]

It has nothing to do with mac4lin project as I have never installed it. Seems that its a Gnome's Virtual FS (gvfs) fault as it never happened before they implemented it. Really.

[Sebastien Bacher (seb128)]

the code has been rewritten in jaunty which deprecate this bug, open new bugs if you have similar issues there

[antonioni (antonioni-rocha)]

"the code has been rewritten in jaunty which deprecate this bug, open new bugs if you have similar issues there"

Will Ubuntu Hardy (LTS) not have this issue corrected? This problem continues in Hardy.

[Sebastien Bacher (seb128)]

> Will Ubuntu Hardy (LTS) not have this issue corrected?

not likely, that's a mostly cosmetic issue happening in some cases only and nobody has been able to provide details on how to trigger it which makes hard to work on the bug, only important bugs and security issues are fixed in stable