Dear Octavian,

trash-put decide in which trash directory store the trashed file according some rules, sometimes it prefers to use ~/.local/share/Trash, sometimes it prefers /mnt/store/.Trash/500, which one it choses depends from the complete path of the file and the partition layout of your file system. So, in order to understand your issue, I need those information:

1. The complete trash-put command you run specifying the absolute filename
2. The output of "df" on your machine.
3. the version of your trash-cli

trash-put creates $topdir/.Trash directories but it should not. It should instead create $topdir/.Trash/500 only when $topdir/.Trash/ already exists and it is sticky, but it does not. This is a known bug that will be solved in the future.

Creating a proper $topdir/.Trash with all permission set right (not only the sticky bit) is an operation that can be done only by a super user. You can fix that using sudo, mkdir and chmod.

from trash-cli.

Now (6246951) trash-put should not create anymore $topdir/.Trash and uses it only when needed.
Feel free to re-open this issue or fill another one, if you have other problems.

from trash-cli.

Hi Andrea,

Thanks for your reply. Below are my answers:

On 10/03/2012 12:05 AM, Andrea Francia wrote:

Dear Octavian,

trash-put decide in which trash directory store the trashed file
according some rules, sometimes it prefers to use
~/.local/share/Trash, sometimes it prefers /mnt/store/.Trash/500,
which one it choses depends from the complete path of the file and the
partition layout of your file system. So, in order to understand your
issue, I need those information:

1. The complete trash-put command you run specifying the absolute filename

$ trash -vi aaaaa
trash: found unusable .Trash dir (should be a dir): /mnt/store/.Trash
trash: `aaaaa' trashed in /mnt/store/.Trash/500
$ which trash
/usr/bin/trash
$ ls -al -d ~/.local/share/Trash
drwxr-x--- 4 44 Sep 30 20:38
/home/octavian/.local/share/Trash

2. The output of "df" on your machine.

rootfs 20G 19G 663M 97% /
udev 10M 4.0K 10M 1% /dev
/dev/md3 20G 19G 663M 97% /
tmpfs 2.0G 260K 2.0G 1% /run
rc-svcdir 1.0M 132K 892K 13% /lib/rc/init.d
none 2.0G 24K 2.0G 1% /dev/shm
/dev/md1 102M 71M 32M 69% /boot
/dev/md4 445G 431G 14G 97% /mnt/store
eeurope:/ 73G 61G 7.9G 89% /mnt/auto/nfs/eeurope
192.168.1.8:/usr 19G 9.3G 9.5G 50% /mnt/auto/nfs/192.168.1.8/usr
192.168.1.8:/var 19G 9.3G 9.5G 50% /mnt/auto/nfs/192.168.1.8/var
192.168.1.8:/opt 19G 9.3G 9.5G 50% /mnt/auto/nfs/192.168.1.8/opt

3. the version of your trash-cli

0.12.9.14-r1 (Gentoo distribution). r1 is just a bump, Thus the version
should be 0.12.9.14

trash-put creates $topdir/.Trash directories but it should not. It
should instead create $topdir/.Trash/500 only when $topdir/.Trash/
already exists and it is sticky, but it does not. This is a known bug
that will be solved in the future.

Creating a proper $topdir/.Trash with all permission set right (not
only the sticky bit) is an operation that can be done only by a super
user. You can fix that using sudo, mkdir and chmod.

Best regards,
Octavian

—
Reply to this email directly or view it on GitHub
#8 (comment).

from trash-cli.

Octavian, thanks for the detailed information, now is clear what was happening.
I think the commit I did solved your problem and if you install the latest version from the trunk this issue should no longer occur.

from trash-cli.

On 10/04/2012 10:53 PM, Andrea Francia wrote:

Octavian, thanks for the detailed information, now is clear what was
happening.
I think the commit I did solved your problem and if you install the
latest version from the trunk this issue should no longer occur.

OK I will apply it to the gentoo ebuild and see the results. I will let
you know.

Best regards,
Octavian

—
Reply to this email directly or view it on GitHub
#8 (comment).

from trash-cli.

Thank you, I look forward for you feedback.

from trash-cli.

On 10/04/2012 11:00 PM, Andrea Francia wrote:

Thank you, I look forward for you feedback.

Unfortunately, it does not fix it.

octavian@aaaa ~ $ touch test-trash-file
octavian@aaaa ~ $ trash test-trash-file
octavian@aaaa ~ $ ll /mnt/store/.Trash/500/files/
total 0
-rw-r----- 1 aaaa aaaaa 0 Oct 4 23:20 test-trash-file
drwx------ 2 aaaa aaaaa 48 Oct 4 23:20 .

I downloaded the files using:

grab the latest sources

wget https://github.com/andreafrancia/trash-cli/tarball/master

unpack and install

tar xfz andreafrancia-trash-cli-xxxxxxxx.tar.gz
cd andreafrancia-trash-cli-xxxxxxxx
sudo python setup.py install

By the way the downloaded file is called master and not
andreafrancia-trash-cli-xxxxxxxx.tar.gz

Furthermore, I have verified few changed lines to see that I have the
latest files from today.

Best regards,
Octavian

—
Reply to this email directly or view it on GitHub
#8 (comment).

from trash-cli.

I can reproduce the bug on my system:

$ echo $HOME
/home/octa
$ ls -la /home  
lrwxrwxrwx 1 root root 16 Oct  7 20:06 /home -> /mnt/store/home/
$ mount 
/dev/sda1 on / type ext3 (rw,errors=remount-ro)
...
/dev/loop0 on /mnt/store type ext2 (rw)
$ touch foo
$ trash -v foo
trash: found unsecure .Trash dir (should be sticky): /mnt/store/.Trash
trash: `foo' trashed in /mnt/store/.Trash/1001

Actual behavior: The file foo is trashed in the /mnt/store/.Trash/1001.
Expected behavior: The file should have been trashed in home trash.

from trash-cli.

The bug does not turn up when the $HOME directory is in another partition but there is not any symbolic link:

andrea@debian:~$ touch foo 
andrea@debian:~$ trash -v foo
trash: `foo' trashed in ~/.local/share/Trash
andrea@debian:~$ df 
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1            297094984    899084 281104344   1% /
/dev/loop0                1003        33       919   4% /home
andrea@debian:~$ trash --version
trash 0.12.10.3~

The bug seems related to the simultaneous presence of the symbolic link and the different partition for the $HOME directory.

from trash-cli.

The bug does not show up when the /home is a symlink:

andrea@debian:~$ ls -l /home
lrwxrwxrwx 1 root root 15 Oct  7 20:29 /home -> /another-place/
andrea@debian:~$ pwd
/home/andrea
andrea@debian:~$ touch foo 
andrea@debian:~$ trash -v foo 
trash: `foo' trashed in ~/.local/share/Trash

from trash-cli.

Hi Andrea,

Any update on this?
I am asking since I am using it in a script.
If you have no time I would try to look into it the next months since my TODO list is spiralling out of control.

Yours sincerely,
Octavian

from trash-cli.

Sorry Octavian I did not found any time to work at trash-cli.
I don't think I can solve your problem.

from trash-cli.

I had this problem, too. The patch is trivial - just use 'realpath' rather than 'abspath' when trying to figure out which mountpoint is associated with a file:

--- a/fstab.py
+++ b/fstab.py
@@ -58,7 +58,7 @@
     def __init__(self, ismount):
         self._ismount = ismount
         import os
-        self.abspath = os.path.abspath
+        self.abspath = os.path.realpath

     def __call__(self, path):
         path = self.abspath(path)

from trash-cli.

Hi Andrea,

Is this patch going to be committed?

Best regards,
Octavian

from trash-cli.

This bug persists:

trash-put: found unsecure .Trash dir (should be sticky): /tmp/.Trash
trash-put: `test' trashed in /tmp/.Trash/1000

I have: "/tmp/.Trash", "/tmp/.Trash-1000", "/tmp/.Trash/1000", "/tmp/Trash", etc...

$ trash --version
trash 0.12.9.14

from trash-cli.