Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Scott Jacobs <scott092707@aol.com> To: Debian Bug Tracking System <submit@bugs.debian.org> Subject: caja: Cannot move file to Trash, do you want to delete immediately? Bcc: Scott Jacobs <scott092707@aol.com> Message-ID: <157231618695.27987.4352493207987785411.reportbug@ASUS-PRIME-B350M-A-CSM> X-Mailer: reportbug 7.5.3 Date: Mon, 28 Oct 2019 22:29:46 -0400 X-Debbugs-Cc: scott092707@aol.com Dear Maintainer, I try to delete a file, but get the above subject text. At first, I thought it was because all of my personal data directories (Documents/Desktop/Pictures/...) are bind-mounted to directories in a separate data partition. However, the rest of /home is within the system partition /, and I get the same result there. If I sudo caja, and try to delete a (copy of a) system file (say, /etc/fstab), this works fine. It appears in /root/.local/share/Trash/files. I DO have a ~/.local/share/Trash/files directory, and my /data partition has a .Trash-1000 directory. I also note, that when I view a picture with eog, invoked from caja's context menu, and hit the delete key, eog also tells me it cannot trash the file, and would I like to delete it. eog apparently inherits the faulty information that caja feeds it. If I use nemo or pcmanfm-qt, there is no problem trashing the files, and if eog is invoked from them, it has no problem trashing them with the delete key as well. (I don't know why ~/.local/share/Trash[/files] is somehow owned by root, but this is not a problem for the other FMs, and I suspect that it is intentional; that individually, trashed files officially ought not to be deleted individually, but are allowed to be deleted en masse when "Empty Trash" is invoked as a command - but this is only a supposition...) I just noticed something interesting: If I try to trash a file in my bind-mounted /data partition, I just get the subject text, but if I try to trash a file in my ~/ directory, I ALSO get the following text, under the "Show more details" arrow: "Unable to find or create trash directory for /home/scott/.reportbugrc (copy)" ----------------------------------------- scott@ASUS-PRIME-B350M-A-CSM:~$ ls -lha / ... drwxrwxr-x 10 scott scott 4.0K Oct 28 20:15 data scott@ASUS-PRIME-B350M-A-CSM:~$ ls -lha /data ... drwxrwxr-x 64 scott scott 4.0K Mar 14 2019 scott drwx------ 5 scott scott 4.0K Feb 28 2014 .Trash-1000 scott@ASUS-PRIME-B350M-A-CSM:~$ ls -lha .local/share drwx------ 4 root root 4.0K Mar 16 2019 Trash scott@ASUS-PRIME-B350M-A-CSM:~$ sudo ls -lha .local/share/Trash ... drwx------ 2 root root 4.0K Mar 16 2019 files drwx------ 2 root root 4.0K Mar 16 2019 info
Having done some investigating, I find that in 4 previous distros I have installed (all Lubuntu), none has had root:root as owners of ~/.local/share/Trash Since the contents of the files directory in that folder in my current Debian install are files that would originally have been in a sub-directory of a system directory, they would have had to be trashed from a sudo-invoked FM; it is at least possible that the trashing caused ownership to change to root:root. However... Most of the files I trash are in my personal directories, in my data partition, and would (should) end up in the /data/.Trash-1000 trash, which as you can see, is owned by me. Unless Caja was trying to trash the files by copying them from the data partition to the system partition trash folder, I cannot see how it had difficulty trashing them. Can anyone enlighten me?
Hi, Am Mittwoch, 30. Oktober 2019 schrieb scott092707@aol.com: On my Ubuntu systems I run a 'sudo chown $user:$user -Rfv ~' in regular intervals... Mike
Update:
Having given myself ownership and permissions to ~/.local/share/Trash[/*],
I am now able to trash items that are in my system / partition (including items that
are in /home/scott that are NOT in the bind-mounted personal data directories)
with no complaint from Caja.
scott@ASUS-PRIME-B350M-A-CSM:~$ ls -lha .local/share
drwxrwx--- 4 scott scott 4.0K Mar 16 2019 Trash
scott@ASUS-PRIME-B350M-A-CSM:~$ ls -lha .local/share/Trash
total 16K
drwxrwx--- 4 scott scott 4.0K Mar 16 2019 .
drwxr-xr-x 19 scott scott 4.0K Oct 29 23:50 ..
drwxrwx--- 2 scott scott 4.0K Mar 16 2019 files
drwxrwx--- 2 scott scott 4.0K Mar 16 2019 info
However, I am still not able to trash files in my bind-mounted directories.
In looking at the terminal output for the trash directory for /data (see above),
I noted that although I had ownership of the directory, only the owner had
permissions for "Create and delete".
I fixed that...
scott@ASUS-PRIME-B350M-A-CSM:~$ ls -lha /data/.Trash-1000
total 4.0M
drwxrwx--- 5 scott scott 4.0K Feb 28 2014 .
drwxrwxr-x 10 scott scott 4.0K Oct 28 20:15 ..
drwxrwx--- 2 scott scott 16K Feb 28 2014 expunged
drwxrwx--- 176 scott scott 1.8M Oct 26 20:48 files
drwxrwx--- 2 scott scott 2.3M Oct 26 20:48 info
...but still had the problem...
AT LAST, I believe I know what the problem is!
I opened the same directory twice, first as:
/home/scott/Pictures/HighestNumbered
then as:
/data/scott/Photos/HighestNumbered
I duplicated a photo.
Caja was unable to trash:
/home/scott/Pictures/HighestNumbered/TGED6979 (copy).JPG
but WAS able to trash:
/data/scott/Photos/HighestNumbered/TGED6979 (copy).JPG
...so Caja has a problem trashing items from areas that are
bind-mounted.
Caja has no problem displaying/copying/moving items, whether their
location is the directory in the /data partition, or in the equivalent
bind-mounted directory within my home directory,
but it CANNOT trash them, if I point it at the home directory equivalent.
Relevant fstab entries:
# <file system> <mount point> <type> <options> <dump> <pass>
UUID=326c8c32-18d2-4322-91d0-ebc73cf9ed0e / ext4 errors=remount-ro,noatime 0 1
UUID=bc0d2436-d89c-4a70-abd0-bb39f092993f /data ext4 defaults,noatime 0 2
...
/data/scott/Desktop /home/scott/Desktop none bind,x-gvfs-hide
/data/scott/Downloads /home/scott/Downloads none bind,x-gvfs-hide
/data/scott/Templates /home/scott/Templates none bind,x-gvfs-hide
/data/scott/Public /home/scott/Public none bind,x-gvfs-hide
/data/scott/Documents /home/scott/Documents none bind,x-gvfs-hide
/data/scott/Music /home/scott/Music none bind,x-gvfs-hide
/data/scott/Photos /home/scott/Pictures none bind,x-gvfs-hide
/data/scott/Videos /home/scott/Videos none bind,x-gvfs-hide
('x-gvfs-hide' is necessary to prevent file managers from displaying each directory as an ejectable device
in Places sidebars and in the /home/<user>/ directory.)