trash-put from non-writable directory copies file to trashcan twice, although reporting an error

[db-inf]

Reporting for trash-cli 0.12.9.14 on XUbuntu 18.04.1. Checked all open and closed issues for duplicates.

Trashing a file from a read-only directory creates both versions of trash-can (.Trash/1000 as well as .Trash-1000) in the top-level directory of the mountpoint, and a copy of the file-to-be-trashed in it both of them, while giving an error message and leaving the original file where it is.

If one version of trash-can pre-exists, trash-put copies the file to that one, realises it cannot delete the original and then creates the other version of trash-can, with another copy of the file in it. And of course still can not delete the original

It can be quite annoying: if you trash a large file you end up with an error message AND 3 copies of the file. The mv command reports an error without making a copy of the file.

Also I don't like the unnecessary write operations associated with copying a file, instead of just moving it out of the way, especially when I consider that file to be not needed anymore.

Here is sample output, executed in the top-level directory of a mountpoint :

$ ls -lAR
.:
total 0
$ mkdir ROdir
$ touch ROdir/new
$ chmod a-w ROdir
$ trash-put ROdir/new 
trash-put: cannot trash regular empty file `ROdir/new'
$ echo $?
74
$ ls -lAR
.:
total 0
drwx------ 3 dirk dirk 60 nov 20 16:03 .Trash
drwx------ 4 dirk dirk 80 nov 20 16:03 .Trash-1000
dr-xr-xr-x 2 dirk dirk 60 nov 20 16:03 ROdir
./.Trash:
total 0
drwx------ 4 dirk dirk 80 nov 20 16:03 1000
./.Trash/1000:
total 0
drwx------ 2 dirk dirk 60 nov 20 16:03 files
drwx------ 2 dirk dirk 60 nov 20 16:03 info
./.Trash/1000/files:
total 0
-rw-rw-r-- 1 dirk dirk 0 nov 20 16:03 new
./.Trash/1000/info:
total 4
-rw------- 1 dirk dirk 60 nov 20 16:03 new.trashinfo
./.Trash-1000:
total 0
drwx------ 2 dirk dirk 60 nov 20 16:03 files
drwx------ 2 dirk dirk 60 nov 20 16:03 info
./.Trash-1000/files:
total 0
-rw-rw-r-- 1 dirk dirk 0 nov 20 16:03 new
./.Trash-1000/info:
total 4
-rw------- 1 dirk dirk 60 nov 20 16:03 new.trashinfo
./ROdir:
total 0
-rw-rw-r-- 1 dirk dirk 0 nov 20 16:03 new

[DrupaListo-com]

version of trash-cli - 0.16.12.28 - using it from a git checkout of that release.

I wanted to report the same and found this report. So +1.
Additionally I can report that this happens even if you delete a symlink to a dir that is not writable - the symink gets deleted to trashcan - all ok - as the symlink itself is writable/deletable, but the destination dir is not writable and stays in place, while a copy of it is put in the trash.
Especially nasty in case of a large directory.
And very frightening because at first one thinks trash-put will/has-just deleted the destination dir. And later you realize it's untouched just copied.

I did not know about the double-copy, so we have two issues stemming from a common cause - the lack of permissions.

I guess what's happening is:

1. a) trash-put always copies the file/dir/symlink before deletion - probably w/o checking write access - and since read access is enough to copy - that copy works.

2. b) Additionally that copy operation dereferences symlinks it seems.
   thought : It might be ok to dereference symlinks of the parent dirs but probably not ok to dereference a symlink we're just trying to delete.

3. After the copy, a deletion phase follows and if no write access - fails. But the copy in the trash is left there.

I have a wrapper that asks me if I want to run sudo trash-put FILE - if normal trash-put FILE fails - so in my case the 2nd attempt with sudo deletes the FILE but still bec of the 1st try I end up with a COPY of FILE/DIR (or if FILE is a symlink to a file/dir - it's destination is copied).

And once again - for large dirs - since the copy process takes time and you can hear your hdd is doing something heavy... you get spooked that maybe trash-put is deleting sth it shouldn't... and you don't know until you 2-check and diff afterwards. I stopped the deletion/copy process with Ctrl+C and diff-ed to make sure all is intact.
There's also the danger of a half-copied large dir that if interrupted in the middle, might leave some subdirs on the original place and some subdirs/files in the destination - i.e. a partial delete. The danger is NOT real in the current case as trash-put just copies and fails to delete anything...but u don't know in advance - the 1st time.

I hope I helped.

[DrupaListo-com]

does this happen with the newest releases?
It's easy to test manually - just try to trash-put a non-writable dir or a symlink pointing to one.

[andreafrancia]

@db-inf the version of trash-cli you mentioned is from 2012. As far I understood the report date if from 2018.
I suggest you to try a newer version of trash-cli, the latest is 0.23.11.10.

As five years have passed, I don't you are still using the Fedora 18 system you mentioned.

In any case, I suggest to do not use the trash-cli from many distributions because they are very old, and newer versions of trash-cli are more secure.

In order to install the latest version of trash-cli use these commands:

sudo yum uninstall trash-cli
pip instal trash-cli

If the problem persist feel free to comment below and I will reopen the issue.

[andreafrancia]

@DrupaListo-com

Thank for your reporting.
If you are stil interested please check the problem still persist in the latest version (0.23.11.10) and fill another issue following the new issue template. The template will help me to get a clearer impression about your issue.