Trash applet [!] when emptying, follow links?

hi,

confirmation needed.

I suspect trash applet to delete not only symlink but also source file or folder to that link.

create a symlink to a folder containing many things.

Put it in trash.

Use trash-applet to empty trash → original folder and its content are deleted.

Create another symlink.

Put it in trash.

Use Nemo to empty trash → only link is deleted, and not original source.

Does anyone confirm ? If so, that sounds like a bug as I don’t expect source to be deleted when deleting a link.

Ubuntu Budgie 19.10 here.

hmm - no I cannot reproduce.

Using 20.04

mkdir oops
touch oops/hi
touch oops/hi2
ln -s oops test

then open nemo and delete the test
Use the applet and empty the trash
Look in oops - both hi and hi2 are there

Indeed.

The problem seems to appear when source and link are not on the same partition.

In that case, the original folder is not deleted, but its content is deleted.

ok - that’s the vital info - yes can confirm if the link is to a second drive (formatted as FAT in my test)

ext4 for the other drive in my case.

I lost today an entire session because of that - thanks I had not too old backup :wink:

Do you agree it’s an annoying behavior ?

More than annoying. It needs to be fixed asap

Please run

ubuntu-bug budgie-extras

Fix needs to be found and pushed out for both 19.10 and 20.04

ok - after you have raised the bug report please can you test a proposed fix?

sudo add-apt-repository ppa:ubuntubudgie-dev/unstable-test
sudo apt upgrade

logout / login.

To uninstall:

sudo ppa-purge ppa:ubuntubudgie-dev/unstable-test

logout / login.

This should only resolve the symlink issue across partitions (without affecting the existing capabilities).

This does not resolve the addition partition trash-can restore/delete issues - that will need to be resolved during the 20.04 cycle.

ubuntu-bug budgie-extras

→ answers « dpkg-query: aucun paquet ne correspond à budgie-extras » → no such package.

ubuntu-bug budgie-trash-applet

https://bugs.launchpad.net/ubuntu/+source/budgie-extras/+bug/1872197

Created folders and files on the extra drive, mounted in /media/DATA

Put link to these in /home/$USER which is on another disc where the whole / partition sits.

Put these links in trash.

Used trash-applet to definitely delete them.

The source files and folders remain as expected on the /media/DATA partition

Test approved !

→ do you mean this → Problems with Trash and Places Applet ?

thx.

yes - that linked issue.

If you can have a play around with normal deletes - symbolic links linking to other folders, embedded symbolic links to other partitions I would appreciate it.

Assuming all is well I will start the upload to 20.04 and 19.10.

Ah ! toying around, I find a folder that applet trash can’t delete…

~/.local/share/Trash/{expunged;files;info} are empty
→ this sounds normal to me as this is the trash in /home/$USER on the / partition whereas the original file to delete is in fact on another partition mounted in /media/DATA

The folder which trash-applet can’t delete is in fact located in
/media/DATA/.Trash-1000/files
→ which also sounds normal to me as « trashes » should be created for each users on any root of any partition ( see what happens eventually on removable media such as external hdd or usb-key ). Yeah, trashes under Linux are a bit thorny.

Of course trash-applet can’t delete this folder nor restore it to its initial place, says « can’t determine the initial place for this file ».

Now I restore this folder, using Nemo and let’s look at its permissions :

django@ASGARD:/media/DATA/coeurnoir/Téléchargements$ ls -la
total 12898300
drwxrwxr-x  3 django maison       4096 avril 11 17:11  .
drwxrwsr-x 53 django maison       4096 avril 11 16:55  ..
(…)
drwxrwxr-x  2 django maison       4096 mars  28 02:24  Photos_téléchargées_avec_AirDroid
(…)

So at first glance, not a permission problem
⋅ django is a member of the maison group
⋅ django and coeurnoir have the same id ( 1000 )

Seems like trash-applet is able to see all the available trashes to user but can only interact with the ~/.local/share/Trash/

If other info needed, ring the bell :wink:

1 Like

We’ll look at this as part of normal development - all useful info to look at and resolve.

Since the key issue of deleting stuff when it shouldnt seems to be resolved I will crack on with the upload stuff. You’ll get a email ping from launchpad when stuff is ready to be tested on 19.10 - the package will be identical to what you have been testing anyway with the exception that it will contain the bug number you raised.

Much appreciated for all of your help.

:blush:

Is it safe I keep the ppa:ubuntubudgie-dev/unstable-test enabled ?

Or should I only download from it the trash-applet .deb until fix ?

Well it’s better being unable to delete some files, than being able to delete unexpected things !

yep - its safe to keep the unstable PPA.

When you get the email ping - please purge the PPA and follow the instructions that Canonical will ask you to verify the new 19.10 proposed package.

Toying further, I’m 99% sure trash-applet only deals correctly with what fall into ~/.local/share/Trash maybe this path is the only one hardcoded in trash-applet ?

see $topdir and $trash → https://specifications.freedesktop.org/trash-spec/trashspec-latest.html

Correct - the author (who has now left unfortunately) didnt take into account other partition trash cans.

That’s what needs to be worked on.

Obviously any help via code patches would be much appreciated to expedite matters

This also explains why I had Applications menu : incomplete keyboard browsing & no recent category where I could not open files from trash.

It’s still true today : using trash-applet I’m able to open files from [user id = 1000]/.local/share/Trash but not those from /media/DATA/.Trash-1000

As a workaround should I link for each user ~/.local/share/Trash to each matching /media/DATA/Trash-* ?
→ auto-answer, not what I expected as this just reverses the situation regarding partitions : what comes from /media/DATA is now handled by trash-applet but not what comes from / partition. So in my context it’s a bit better since only the root of /home/$USER is really located on /
→ but confirms only ~/local/share/Trash is taken care by trash-applet, as long as files-put-on-deletion share the same partition
→ now if I try to delete something from the root of /home/$USER, I have a warning « unable to put it in trash - do you want to definitely delete ? »

A bit later.

I get back to normal regarding ~/.local/share/Trash which is now a real folder, and not a link.

I can indeed put in trash files from /home/user_1001 and from /media/DATA/user_1001 and delete those files through trash-applet.

But I won’t be able to restore through trash-applet the file coming from /media/DATA/user_1001

And there’s a little visual difference between those files :
trash_applet
⋅ one shows no time stamp → the one I can’t restore through trash-applet → right now sits in /media/DATA/.Trash-1001.
⋅ I’m able to restore it through Nemo’s trash, though → which shows trash:/// as path
⋅ other file with time stamp comes from /home/user1001 → right now sits in ~/.local/share/Trash.

Exact same behavior with users 1000, 1001, 1002.

tl;dr

the « time » info is not shown in trash-applet for files outside ~/.local/share/Trash

Maybe it’s a hint ?

Thx for the feedback.

Will feed that back into development.

BTW did you get the ping from Canonical? The release patch is patch is ready to test. Instructions on your bug report.

Thx

No ping from canonical…