trash applet refers to a different folder than the default one in ubuntu

The folder /home/username/.local/share/Trash/ doesn't seem to exist on Ubuntu 7.10 for me.

Both the trash applet on the gnome panel and awn use /home/username/.Trash on my system.

I'm betting that this is either a hardy system or a non-Gnome desktop.

someone in the net says that the standard gnome folder for the trash is that one in .local/share ...
what is true?
does ubuntu were non-standard until now or is he becamed non-std?

in order to complete the bug explanation:
system in use: hardy (wich has the default folder in home/username/.local/share/trash)
awn: 2.3 from trunk repository
awn-extras: 2.3 from trunk repos too
affects all the trash applets that point to home/username/.trash

is there a fix in an earlier version or a workaround?

I can confirm that Hardy is now using ~/.local/share/Trash as it's trash dir.

Freedesktop Spec for Trash: http://www.ramendik.ru/docs/trashspec.html

It should be: $XDG_DATA_HOME/Trash

Work around: You can manually set the directory used by Trasher in gConf. avant-window-navigator/applets/Trasher/ trash_dirs

Some further investigation....

Trasher includes libgnomevfs/gnome-vfs.h Ubuntu has replaced gnome-vfs with GIO and gvfs in Hardy. Which seems to be the way that Gnome as a whole is headed. This is probably the root of the problem here.

This is a little strange....? ver 0.2.3 ???

With AWN ver 0.2.6 (latest) and Hardy fully updated the Trash goes correctly to trash:///

The Trash stacker also seems to point correct.

-----------------------------------------------------------

The Stacks file operations must also be tested....:)

The bug is 100% correct, I had old files within the old folder.

This is the situation with the GIO port

http://live.gnome.org/GioPort

some detailed informations for the workaround?
thank ya

"some detailed informations for the workaround?"

Not sure. I"m not sufficiently familiar with the code involved and other changes that may have occurred in the handling of Trash to recommend anything. Trash applets in general concern me and I'd feel more comfortable if the awn trash applets were not used in a gio based environment until someone takes some time to sit down and have look at them.

I can think of a few workarounds but I'm hesitant to suggest using them as I'm not sure of the ramifications... all would probably be well, but when you're basically dealing with code that deletes files it's best to be careful. Maybe I'm just paranoid though :-)

Shouldn't just manually changing the gconf key: avant-window-navigator/applets/Trasher/trash_dirs be an acceptable work around? I haven't tried it yet. What ramifications might this have? Why does a gconf key exist if you shouldn't change it?

Andrew,

I think it is probably fine.... I can't see why it would cause anything catastrophic. But like I said earlier, I'd be happier if some would confirm that such a change is safe before we recommend it as an workaround.

My only concern is that the two Trash implementation are compatible. I suspect it'll be fine... but I don't _know_ that. I haven't read the relevant documentation and don't expect I will for a bit... I'm hoping someone else will though.

Andrew,

Although untested it shouldn't be a problem changing the gconf key.
The gcon key exist because stacks trasher is just a specific version of the stack applet.

I don't know why you have this gconf key: avant-window-navigator/applets/Trasher/trash_dirs though?
it should be something like: avant-window-navigator/applets/stacks/trasher/trash_dirs/backend
default it should be set to "trash:"

I have keys for both backend and trash_dirs. See Attached.

On Sun, Feb 24, 2008 at 8:45 AM, Silentstorm <email address hidden> wrote:
> Andrew,
>
> Although untested it shouldn't be a problem changing the gconf key.
> The gcon key exist because stacks trasher is just a specific version of the stack applet.
>
> I don't know why you have this gconf key: avant-window-navigator/applets/Trasher/trash_dirs though?
> it should be something like: avant-window-navigator/applets/stacks/trasher/trash_dirs/backend
> default it should be set to "trash:"
>
>
>
> --
> trash applet refers to a different folder than the default one in ubuntu
> https://bugs.launchpad.net/bugs/194431
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Just looked a bit closer to the code those entries aren't really used for trasher

trasher gets the trash dirs by doing gnomevfs.Volume.handles_trash for every mounted volume ...

that's probably why it isn't working for you ...

Has there been any progress in resolving this bug or coming up with a tried workaround?

As far as I know, there hasn't been any work on it.

Bummer.

I had the same problem....and upon further investigation I found that dragging and icon onto the awn trash icon places the file in ~/.Trash while right clicking on a file in nautilus and selecting "move to trash" place the file in ~/.local/share/Trash/files.

The following solution worked for me: I deleted the directory ~/.local.share/Trash/files and made a symlink with the same name pointing to ~/.Trash

Eugene,

Thanks for the workaround. What would I code in the terminal to make such a symlink?

Thanks,
Vaughn

I feel I should discourage people from the above work around. ~/.local/share/Trash/ is the new location of Trash for Gnome systems. Using the work around above will most like lead to other issues if you are on a gvfs enabled Gnome system (ie Ubuntu Hardy). If you want to use a symlink as a work around it would probably be a better bet to do the reverse of what Eugene suggests.

try this:

rmdir ~/.local/share/Trash/files
ln -s ~/.Trash ~/.local/share/Trash/files

Or as Andrew suggests:
rmdir ~/.Trash
ln -s ~/.local/share/Trash/files ~/.Trash

disclaimer: I'm no guru
opinion: I can't see how either would have any effect on hardy at all...I've been using this on hardy for 3+ weeks without issue .....both solutions change nothing but instead of having these 2 trash directories one becomes a sym link....if in the future (hardy +1) they decide to change things around, if you keep your home directory, the new trash directory (.local) will still appear to be there to the OS....and if they decide to do away with ~/.Trash it shouldn't cause any problems to have it there anyways

I'll take this one, but I'm warning you all, this is probably going to take a while, as porting to GIO is a rather annoying process.

WARNING
if you use any of the above workarounds (BTW the second is better), _dont_ empty trash from the applet's menu, click on it to open the trash in nautilus, and then empty it _from there_ (this is to remove some .trashinfo files).

i did'nt understand the warning could you please explain that

how (if possible) can i reverse this workaround ?

to reverse the work around:
if you did the first way I posted....this:
rmdir ~/.local/share/Trash/files
ln -s ~/.Trash ~/.local/share/Trash/files

then do this:
rm ~/.local/share/Trash/files
mkdir ~/.local/share/Trash/files

and if you used the second method (as suggested by andrew):
rmdir ~/.Trash
ln -s ~/.local/share/Trash/files ~/.Trash

then do this:
rm ~/.Trash
mkdir ~/.Trash

Don't you all find that having a trash with no .trashinfos, just plain files in a plain folder (the old way), a hell of alot simpler? I certainly do.

The new way is a desktop standard. Personally, I like interoperability between desktops. Makes my job easier.

This problem appears to have began for me after installing wine, and utorrent, and it appears that only files deleted using utorrent are appearing there. All other files deleted show up in the normal trash location. Also I noted that when I later installed the KDE and XFCE desktops and boot using them instead of Gnome, the files can be deleted from the trash which are contained in /home/user/.local/share/Trash.

Working on porting the code to use GIO.

thank you

This does not affect Ubuntu per se because there is no awn-extras-applets package in Ubuntu (yet).

There is a bzr package in ubuntu. Its unstable, but you couldn't tell by using it (most of the time). It provides applets.

That is not what I meant. There is no official "awn-extras-applets" package in the official Hardy or Intrepid repositories. The package you're referring to is from a third-party repository, which is unsupported by Ubuntu developers.

You could look into the trash screenlet, it's working fine here.
Maybe you could make a new trash applet based on the trash screenlet...

I am currently writing a new trash applet (called Garbage) in Vala, because refactoring the existing trash applet is non-trivial. I had "finished" a port, but it was extremely buggy. Writing the new one is a slow process, mainly because I've been rather busy at my job. However, the code itself is relatively simple, and a good example (in my opinion) of an applet of simple-to-medium complexity written in Vala. I need to finish writing the UI and the Gnome VFS/Thunar VFS backends, but the GIO backend is more or less finished.

I believe this is no longer Invalid in Ubuntu as awn-extras-applets is currently in Intrepid, 0.2.6-2, https://launchpad.net/ubuntu/intrepid/+source/awn-extras-applets/.

Redirecting all trash to ~/.local/share/Trash/files does not fully solve the problem

Correct implementation of trash will require:

1) Integration of all trash in all volumes, not just home
2) Displaying of original file names, not mangled ones
3) Display of metadata from Trash/info: delete date, original file path
4) Implementation of a restore option for trashed files

Gnome's trash applet currently does 1 and 2, but not 3 and 4.

Items deleted from another volume are found in "[path to mountpoint]/.Trash.-[Owner's UID]"
Deleting something that has the same name as an item in the trash gives it an incrementing extension starting with appending a .2 to the name

Well, for the purposes of the trash applet rewrite that's going into Awn Extras version 0.2.8, I'm only going to have feature parity with the current gnome-vfs based trash applet. Implementing a "proper" trash applet is outside the scope of this bug. Depending on time and willingness, points 3 and 4 may or may not be implemented in a 0.4.0 or later release.

Please file a bug with the gnome-applets project regarding points 3 and 4 if they haven't been filed already. I'm sure that the GNOME developers wish to be as correct regarding the trash specification as possible.

I should be more careful with my wording -- 3 and 4 are really just obvious next-step features given the metadata required by the trash spec.

Achieving 1 will get you feature parity with the gnome trash applet and should be enough work. You will probably also have to generate the metadata files and throw the trash in the correct trash volume on drag and drop. The gnome applet simply summons nautilus with trash:/// as an argument to handle displaying the files.

You'll need to implement 2 (reassembling names from metadata) to get stacks working. I was incorrect above when I mentioned a filename pattern -- this is just how the gnome implementation works and the filenames in $trash/files need not have any specific relation to the original filename. It will unfortunately be necessary to parse the filename out of the path key in the corresponding .trashinfo metadata file.

I may file 3 and 4 as questions for gnome-applets if there's nothing that mentions file restore or delete dates.

Per above, will be nice to see the implementation of the additional points in Gnome - take advantage of the new spec, otherwise not much benefit to the user.

For those who scroll to the bottom of this thread for the workaround - IMHO, best defer to the system location and use Andrew's -

rmdir ~/.Trash
ln -s ~/.local/share/Trash/files ~/.Trash

then do this:
rm ~/.Trash
mkdir ~/.Trash

[QUOTE]
then do this:
rm ~/.Trash
mkdir ~/.Trash
[/QUOTE]

Now that makes no sense ... Mind you, that part is to UNDO the first part and restoring the original situation. This is because the proposed workaround didn't take the new Gnome/Hardy trash-structure into account. When using this workaround you will not be able to put files on different mount-points correctly into your trash-can. (see Toaste on 2008-07-30 for reasons)

So, I just upgraded to Ubuntu 8.10 Intrepid Ibex. Guess what? The trash applet seems to work now.

for a more elegant fix, (which will also allow you to use the stacks trasher)... open your /etc/fstab file:

$ gksu gedit /etc/fstab

and add the following code to the end:

/home/<username>/.local/share/Trash/files /home/<username>/.Trash none bind

don't forget to replace <username> with your actual username ;)

if you want to make it work right now! with no reboot...

$ sudo mount -a

In Intrepid, trash applets seems to work as expected, pointed to the right location of the trash.

in jaunty it seems to be broken again

I can verify that this applet is not working in Jaunty 32-bit or 64-bit. No errors are thrown. Things that are deleted using the delete key do not appear in the awn trash applet's trash folder.

It seems that the trash:// path is broken, not the applet itself.
Could you please try to open the trash with nautilus to see if you can reproduce the behavior ?

Julien,

When I open the trash in nautilus from the sidebar, it works fine and contains everything I've thrown away. I can also empty the trash from nautilus without a problem. By the way, when I open the trash in nautilus and press Ctrl-L, the address displayed is trash:/// (note the extra trailing slash that you don't have in your path above).

Thanks,
Vaughn

Hello Again Julien, et. al.,

The trash path in Nautilus is not broken and the Ubuntu Jaunty trash panel applet works fine. Ubuntu or Gnome must have changed the path again. This seems to affect both of AWN's trash applets. As mentioned above though, the nautilus path to trash is show as trash:/// (could the extra slash be the problem?).

+1
in jaunty

Retargeting to 0.4 version of Awn-Extras.

I forgot about this bug, but it was fixed for me since months with the awn from the awn-testing repository.

Um, I'm on awn-testing, and it still isn't working for me on either of my computers (both Ubuntu 64-bit).

I'm actively working on a replacement trash applet (called Garbage - creative, huh? :) ). It will definitely be in Awn Extras 0.4, and I will announce on this bug when it's ready for testing.

Glad to hear it Mark! By the way, when is .4 coming out?

Never mind. I just saw the target date of 10/16/09.

FWIW, that's not a hard deadline. If it's not ready at that date, it'll get pushed back.

Um, this is definitely "Fix Released" in Lucid.