Bug 178479 - trash io slave does not use $topdir/.Trash or $topdir/.Trash-$uid directories as described in the freedesktop.org spec
Summary: trash io slave does not use $topdir/.Trash or $topdir/.Trash-$uid directories...
Status: RESOLVED FIXED
Alias: None
Product: kio
Classification: Frameworks and Libraries
Component: trash (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: David Faure
URL:
Keywords:
: 179728 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-12-22 16:23 UTC by Marc Schiffbauer
Modified: 2009-02-09 22:52 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marc Schiffbauer 2008-12-22 16:23:32 UTC
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
Comment 1 David Faure 2008-12-22 18:38:30 UTC
> 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.
Comment 2 Marc Schiffbauer 2008-12-22 22:56:11 UTC
(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.

Comment 3 David Faure 2008-12-24 14:20:49 UTC
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.
Comment 4 Marc Schiffbauer 2008-12-25 18:53:03 UTC
(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?

Comment 5 John Beranek 2008-12-25 23:39:10 UTC
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.
Comment 6 FiNeX 2009-01-06 15:23:25 UTC
*** Bug 179728 has been marked as a duplicate of this bug. ***
Comment 7 Marc Schiffbauer 2009-01-08 05:43:01 UTC
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.
Comment 8 Zen 2009-01-08 22:39:53 UTC
My system is LVM free and this is bugging me none the less.
Comment 9 David Faure 2009-01-08 22:48:56 UTC
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...
Comment 10 Marc Schiffbauer 2009-01-09 01:53:36 UTC
(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
Comment 11 Marc Schiffbauer 2009-01-09 03:52:36 UTC
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?
  



Comment 12 Marc Schiffbauer 2009-01-09 18:16:00 UTC
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.
Comment 13 Zen 2009-01-10 00:16:05 UTC
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.
Comment 14 David Faure 2009-01-26 17:41:22 UTC
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
Comment 15 John Beranek 2009-02-09 22:02:00 UTC
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
Comment 16 Kevin Kofler 2009-02-09 22:13:10 UTC
FYI, the patch we added is exactly the same which went into 4.2.1 (comment #14). It doesn't seem to work.
Comment 17 Marc Schiffbauer 2009-02-09 22:21:52 UTC
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.

Comment 18 John Beranek 2009-02-09 22:23:48 UTC
My root partition is on an LVM volume, yes.
Comment 19 John Beranek 2009-02-09 22:32:38 UTC
(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.
Comment 20 Marc Schiffbauer 2009-02-09 22:52:57 UTC
OK, I will close this bug then.