Version: 4.1.85 (using Devel) OS: Linux Installed from: Compiled sources trash io slave does not use $topdir/.Trash or $topdir/.Trash-$uid directories as described in the freedesktop.org spec It *always* moves trashed files to $XDG_DATA_HOME/Trash which is bad in many situations. As described in the freedesktop.org trash spec trashed files on another partition should be trashed to that same partition when possible. Two possibilities must be supported then: 1.) $topdir/.Trash-$uid if this exists or the user has write permissions to $topdir or 2.) $topdir/.Trash/$uid (where .Trash must have sticky bit set) both cases are not used by the trash io slave, so if a user trashes many/big files on another partition than the home-partition might fill-up the users home dir and take a lot of time. Note: In the current implementation, if the user has write permissions to the partition ($topdir) the $topdir/.Trash-$uid directory is being created but not used. So I assume the code is there but has a bug. The spec: http://www.ramendik.ru/docs/trashspec.html
> trash io slave does not use $topdir/.Trash or $topdir/.Trash-$uid directories It certainly does. My guess is that the permissions on the dirs you created are not strict enough. > $topdir/.Trash-$uid if this exists or the user has write permissions to $topdir ... and .Trash-$uid is owned by the user, and has mode 0700. > $topdir/.Trash/$uid (where .Trash must have sticky bit set) ... and user does NOT have write perm to .Trash, and $uid is owned by user and has mode 0700.
(In reply to comment #1) Hi David, several situations are possible: > > trash io slave does not use $topdir/.Trash or $topdir/.Trash-$uid directories > > It certainly does. My guess is that the permissions on > the dirs you created are not strict enough. Well, the trash io slave created the directory... I tested with the user (mschiff) having write-permissions to $topdir and with *no* existing $topdir/.Trash* I used my /opt partition for testing: root@bart:/opt# df -h|grep opt /dev/mapper/vg00-opt 4,0G 759M 3,0G 20% /opt root@bart:/opt# root@bart:/opt# ls -la /opt | egrep "( .$|.Trash*)" drwxr-xr-x 8 mschiff root 4096 2008-12-22 22:19 . root@bart:/opt# now I create a dir foo with some file bla.wav and subdir bla with another bla.wav as the user and move them to trash after that. mschiff@bart:/opt$ ls -lR foo foo: insgesamt 10260 drwxr-xr-x 2 mschiff mschiff 4096 2008-12-22 16:26 bla -rw-r--r-- 1 mschiff mschiff 10485760 2008-12-22 15:30 bla.wav foo/bla: insgesamt 20504 -rw-r--r-- 1 mschiff mschiff 20971520 2008-12-22 15:32 bla.wav mschiff@bart:/opt$ -> now I use dolphin to move everything below foo to trash. -> (dolphin crash, already reported and fixed ;)) Now the dir /opt/.Trash-1000 has been created (correct uid) with subdirs "files" and "info" but no other files inside. Instead they got moved to my home trash: drwx------ 4 mschiff mschiff 4096 2008-12-22 22:25 .Trash-1000 mschiff@bart:/opt$ find .Trash-1000/ .Trash-1000/ .Trash-1000/files .Trash-1000/info mschiff@bart:/opt$ find /home/mschiff/.local/share/Trash/ /home/mschiff/.local/share/Trash/ /home/mschiff/.local/share/Trash/info /home/mschiff/.local/share/Trash/info/bla.wav.trashinfo /home/mschiff/.local/share/Trash/info/bla.trashinfo /home/mschiff/.local/share/Trash/files /home/mschiff/.local/share/Trash/files/bla /home/mschiff/.local/share/Trash/files/bla/bla.wav /home/mschiff/.local/share/Trash/files/bla.wav mschiff@bart:/opt$ > > > $topdir/.Trash-$uid if this exists or the user has write permissions to $topdir > > ... and .Trash-$uid is owned by the user, and has mode 0700. see above it got created by the io-slave but files were not moved to the new dir but to home trash instead > > > $topdir/.Trash/$uid (where .Trash must have sticky bit set) > > ... and user does NOT have write perm to .Trash, and $uid is owned by user and > has mode 0700. > ?? No, thats not how it should be. User *needs* write permission to .Trash to be able to create the $uid dir inside. Therefor .Trash needs the sticky bit like /tmp for example. from the spec: "(1) An administrator can create an $topdir/.Trash directory. The permissions on this directories should permit all users who can trash files at all to write in it.; and the “sticky bit” in the permissions must be set, if the file system supports it." So next test was with no write permissions to /opt for the user but with an existing /opt/.Trash with 777 permissions and sticky-bit set. root@bart:/opt# root@bart:/opt# chown root . root@bart:/opt# mkdir .Trash root@bart:/opt# chmod 0777 .Trash/ root@bart:/opt# chmod o+t .Trash/ root@bart:/opt# l insgesamt 48 [...] drwxr-xr-x 2 mschiff root 4096 2008-12-22 22:32 foo drwxrwxrwt 2 root root 4096 2008-12-22 22:48 .Trash [...] root@bart:/opt# Now after creating the same files again I trash them again in the same way as in the previous test. Result: files got moved to my home trash again which is wrong too. User mschiff has write permissions to /opt/.Trash and the trash ioslave should have had created /opt/.Trash/1000 with 0700 perms instead and moved the files to that new dir, but nothing has been created there.
I did your first test here (user-writable partition, .Trash-1000 gets created automatically with mode 0700), and it worked fine (the files get trashed into it). So the permissions are not the problem, something else is making kio_trash refuse to use the partition in your case. Do you have kdebase compiled in debug mode? kio_trash's debug output should be in ~/.xsession-errors (if you started kde via kdm), otherwise start kdeinit4 from a terminal first and the output will appear there. The interesting part of the debug output starts with "TrashImpl::initTrashDirectory", please paste that line and the 10 lines after that. -- About the other setup, you're right, I read the code wrong. .Trash must be writable and sticky, while .Trash-$uid must be 0700. I guess it's the same issue as the first setup though.
(In reply to comment #3) > I did your first test here (user-writable partition, .Trash-1000 gets created > automatically with mode 0700), and it worked fine (the files get trashed into > it). I retried this with a non-LVM Partition, and his worked! (on my /boot). But back to /opt: This is the kio_trash debug output for /opt (on LVM) I created using the neon nightlybuilt packages with another user (tail -f .xsession-errors|grep kio_trash). > So the permissions are not the problem, something else is making kio_trash > refuse to use the partition in your case. Do you have kdebase compiled in debug > mode? kio_trash's debug output should be in ~/.xsession-errors (if you started > kde via kdm), otherwise start kdeinit4 from a terminal first and the output > will appear there. > The interesting part of the debug output starts with > "TrashImpl::initTrashDirectory", please paste that line and the 10 lines after > that. kio_trash(29117) TrashImpl::initTrashDirectory: "/opt/.Trash-1001" kio_trash(29117) TrashImpl::initTrashDirectory: kio_trash(29117) TrashImpl::testDir: "/opt/.Trash-1001/info" created. kio_trash(29117) TrashImpl::testDir: "/opt/.Trash-1001/files" created. kio_trash(29117) TrashImpl::findTrashDirectory: mountPoint= "/opt" trashDir= "/opt/.Trash-1001" kio_trash(29117) TrashImpl::createInfo: trashing to 0 kio_trash(29117) TrashImpl::createInfo: trying to create "/home/kde4test/.local/share/Trash/info/test.txt.trashinfo" kio_trash(29117) TrashImpl::createInfo: info file created in trashId= 0 : "test.txt" kio_trash(29117) TrashProtocol::copyOrMove: calling moveToTrash( "/opt/kde-test/test.txt" 0 "test.txt" ) kio_trash(29117) TrashImpl::moveToTrash: kio_trash(29117) TrashImpl::directRename: "/opt/kde-test/test.txt" -> "/home/kde4test/.local/share/Trash/files/test.txt" kio_trash(29117) TrashImpl::error: 108 "rename" Hm I see no obvious error, do you? I find it a bit strange that trashing to /boot/.Trash-1001 works, but trashing to /opt/.Trash-1001 does not (double checked it). Debug output on /boot: kio_trash(30135) TrashImpl::initTrashDirectory: "/boot/.Trash-1001" kio_trash(30135) TrashImpl::initTrashDirectory: kio_trash(30135) TrashImpl::testDir: "/boot/.Trash-1001/info" created. kio_trash(30135) TrashImpl::testDir: "/boot/.Trash-1001/files" created. kio_trash(30135) TrashImpl::findTrashDirectory: mountPoint= "/boot" trashDir= "/boot/.Trash-1001" kio_trash(30135) TrashImpl::findTrashDirectory: known with id 8001 kio_trash(30135) TrashImpl::createInfo: trashing to 8001 kio_trash(30135) TrashImpl::createInfo: trying to create "/boot/.Trash-1001/info/kde-test.trashinfo" kio_trash(30135) TrashImpl::createInfo: info file created in trashId= 8001 : "kde-test" kio_trash(30135) TrashProtocol::copyOrMove: calling moveToTrash( "/boot/kde-test2/kde-test" 8001 "kde-test" ) kio_trash(30135) TrashImpl::moveToTrash: kio_trash(30135) TrashImpl::directRename: "/boot/kde-test2/kde-test" -> "/boot/.Trash-1001/files/kde-test" And trashing to $topdir/.Trash does not work on both though. Anything else I can test/try?
I posted bug 177023 about Dolphin (and Konqueror 4) not using $topdirs when trashing, and I was pointed at this bug by David Faure. The bug report is for KDE 4.1.3 on openSUSE, but I have furthermore confirmed it on Fedora 10, which also ships with KDE 4.1.3 currently. As I said in that bug: Permissions should not be an issue: $ ls -ld /.Trash drwxrwxrwt 3 root root 4.0K 2008-07-09 10:55 /.Trash/ $ ls -ld / drwxr-xr-x 32 root root 4.0K 2008-12-10 15:18 // If I delete a file on the / partition, it is moved to $HOME/.local/share/Trash, which is an NFS mounted home directory.
*** Bug 179728 has been marked as a duplicate of this bug. ***
It seem very likely to me that this "bug" is caused by HAL not being able to recognize filesystems on LVM :-( "hal does not recognize LVM or MD volumes" -> see http://bugs.freedesktop.org/show_bug.cgi?id=6427 this bug is more than one year old, a patch exists but the problem has not been fixed yet so everyone using LVM these days (default on fedora for example!) will have problems with kio_trash and other things like the disk-monitor plasmoid for example.
My system is LVM free and this is bugging me none the less.
Well, Zen, I need more infos about why it doesn't work for you, you need to check the permissions precisely and report what kio_trash says (in ~/.xsession-errors, and you'll get more output if you compile kdebase in debug mode). No crystal ball here to guess why it doesn't work for you, if it's not LVM nor NFS nor a permission problem...
(In reply to comment #8) > My system is LVM free and this is bugging me none the less. > @Zen: you might try two things: 1. trashing on a partition *with* write access for the user at the $topdir (a directory $top-dir/.Trash-<uid> will be created automatically containing the trashed files) 2. trashing on a partition *without* write access for the user in $topdir but with a proper $topdir/.Trash directory (this is with rwxrwxrwt properties) -Marc
Hi again, I wrote myself a shellscript that adds all the LVM devices to hal manually. This way I could continue to test kio_trash. trashing to user writable partitions works fine then. But I still noticed two issues here: 1. trashing to a partition that is *not* user writable but contains a $topdir/.Trash with rwxrwxrwt permissions does *not* work. Files are still getting moved to home dir. I might add debug output later if needed. 2. a minor thing: while testing I removed the $topdir/.Trash-<UID> directory from the partition and changed back the perms of the partition to root:root. Now when trying again to trash something dolphin got an error that it was not able to write to the $topdir/.Trash-<UID> directory and trashing failed completely (file still in old place). So it seems that there is some invalid cache somewhere that has not been refreshed when the root-inode of the device had changed. Any idea?
Some additional info: I added debug output for all the tests that are done on the $topdir/.Trash directory before using it. One test fails that should not: ::access(rootTrashDir_c, W_OK) If I remove that test everything works fine (I trashed a foobar.txt. Directory looks like this: drwxrwxrwt 3 root root 4096 2009-01-09 18:07 .Trash /opt/.Trash/ /opt/.Trash/1001 /opt/.Trash/1001/files /opt/.Trash/1001/files/test2 /opt/.Trash/1001/files/test2/foobar.txt /opt/.Trash/1001/info /opt/.Trash/1001/info/test2.trashinfo I do not know why the ::access() test does not succeed, but users can actually write to the trash dir.
On my partition with write access in $top-dir the .Trash-<uid> folder is automatically created and then files are moved to the home trash anyway! On an USB-stick (FAT) no auto creation of .Trash-<uid>, creating .Trash doesn't help either (advanced permissions like sticky bit not possible on FAT anyway if I'm not mistaken). Sorry, can't provide debug output as I can't compile in debug mode here.
SVN commit 916987 by dfaure: Fix wrong fix for 142148, I missed the ==0 so the logic was reversed, oops. CCBUG: 142148 CCBUG: 178479 This fix will be in 4.2.1, probably not in 4.2.0. M +4 -2 trashimpl.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=916987
I raised a bug in Redhat's Bugzilla for this <https://bugzilla.redhat.com/show_bug.cgi?id=481598> and they added a patch for their version of KDE 4.2.0. However, as I posted on their bug, the fix didn't work. === Not working here, deleted a file in /tmp and it didn't end up in my /.Trash but instead in my NFS mounted home directory. # rpm -qa|grep kdebase kdebase-runtime-4.2.0-3.fc10.x86_64 kdebase3-pim-ioslaves-3.5.10-4.fc10.x86_64 kdebase-workspace-libs-4.2.0-4.fc10.2.x86_64 kdebase3-libs-3.5.10-4.fc10.x86_64 kdebase-libs-4.2.0-2.fc10.x86_64 kdebase-workspace-4.2.0-4.fc10.2.x86_64 kdebase-4.2.0-2.fc10.x86_64 kdebase3-3.5.10-4.fc10.x86_64 kdebase-runtime-libs-4.2.0-3.fc10.x86_64 # ls -la /.Trash/ total 16 drwxrwxrwt 3 root root 4096 2008-07-09 10:55 . drwxr-xr-x 32 root root 4096 2009-02-02 08:40 .. drwx------ 4 beranej1 beranej1 4096 2008-07-09 10:55 20158
FYI, the patch we added is exactly the same which went into 4.2.1 (comment #14). It doesn't seem to work.
Please note that this fix does *not* seem to work if you use LVM. But this is another issue and not a bug in thr kio-slave. (Its not working with LVM atm because HAL does not support LVM LVs). I wrote a litte shell-script-hack that adds my LVs to HAL which makes kio_trash work fine then. AFAIK RH / FC uses LVM by default so I think this might be the problem there.
My root partition is on an LVM volume, yes.
(In reply to comment #18) > My root partition is on an LVM volume, yes. > Needless to say, I didn't fully read your comments on the bug Marc, sorry.
OK, I will close this bug then.