GNOME Bugzilla – Bug 789328
Trash restore moves files to wrong location
Last modified: 2017-12-14 14:10:40 UTC
When using "restore" from the Gnome trash can, instead of moving the item to the original location, it's moved inside the .Trash directory. This only happens on additionally-mounted drives (i.e. / and /home work fine). Example follows: mount point: /mnt/data my user id: 1000 trash location: /mnt/data/.Trash "trashing" file /mnt/data/example_path/example_file moves it to /mnt/data/.Trash/1000/files/example_file The file appears in the Gnome trashcan with the correct original path listed. restoring the file from Gnome trashcan moves it to /mnt/data/.Trash/example_path/example_file Of note, when the file is in the .Trash, the info file has a relative path: [Trash Info] Path=example_path/example_file DeletionDate=2017-10-20T17:18:29 On another note, installing trash-cli and using restore-trash works as expected, so maybe the relative path is not the issue, just the restore functionality of gvfs.
Thanks for your report, is trash::orig-path attribute also wrong? gvfs-info -a "trash::orig-path" trash:///[the_problematic_file]
$ gvfs-info -a "trash::orig-path" trash:///example_file Error getting info: No such file or directory
Ah, sorry, it happens probably only with non-home trashes, where the URIs need to be escaped correctly, which is not obvious... nevermind. Just for info, the correct URI can be found using the following: $ gvfs-ls trash:/// trash:///%5Crun%5Cmedia%5Coholy%5CBE41-EC1C%5C.Trash%5C1000%5Cfiles%5Cempty.txt ...and then can be used for e.g. gvfs-info: $ gvfs-info trash:///%5Crun%5Cmedia%5Coholy%5CBE41-EC1C%5C.Trash%5C1000%5Cfiles%5Cempty.txt uri: trash:///%5Crun%5Cmedia%5Coholy%5CBE41-EC1C%5C.Trash%5C1000%5Cfiles%5Cempty.txt attributes: trash::orig-path: /run/media/oholy/BE41-EC1C/.Trash/empty.txt ...the orig-path is obviously wrong in case of trash dir which consists of more directories, i.e. ".Trash/$UID", though it works correctly for trashes in form of ".Trash-$UID". GIO uses the latter form preferably, so that's probably the reason why the bug was not found earlier...
Created attachment 362149 [details] [review] trash: Fix trash::orig-path for relative paths The trash::orig-path attribute calucaltion expects that the trash is only one dir (i.e. .Trash, .Trash-$UID) and it fails for relative paths in case it is not (i.e. .Trash/$UID). Let's propagate the topdir and fix relative path handling...
Don't you have a chance to test the attached patch?
I think you're on the right track... $ gvfs-info -a "trash::orig-path" trash:///%5Cmnt%5data%5C.Trash%5C1000%5Cfiles%5Cexample_file attributes: trash::orig-path: /mnt/data/.Trash/example_path/example_file I don't know if I can help you test the patch without some direction as to what/how to compile with the patch and where to stick the result...
compiled gvfs with patch. No fix. Same exact result as above
I don't know how did you build the gvfs sources and where did you install them. But I suppose that the main gvfs daemon doesn't see the newly built gvfsd-trash binary and the system version is running instead. Check the path using "ps ax | grep gvfsd-trash". Probably the easiest way of testing is to run the newly built gvfsd-trash daemon from builddir manually: "pkill gvfsd-trash; ./daemon/gvfsd-trash". Does it help? What distribution do you have? (I have to write down some notes for testers finally).
Sorry for disappearing. I have re-tried compiling gfvs from source with your patch and replacing gvfsd-trash and gvfs-trash with resulting binaries. Unfortunately, I was unable to test for the bug because, replacing the binaries caused other errors: org.gtk.vfs.Daemon[1794]: mkdir: cannot create directory ‘/usr/lib/gvfs/.libs’: Permission denied org.gtk.vfs.Daemon[1794]: /usr/bin/ld: cannot open output file /usr/lib/gvfs/.libs/4327-lt-gvfsd-trash: No such file or directory org.gtk.vfs.Daemon[1794]: collect2: error: ld returned 1 exit status I would not doubt that this was caused by some error that I made, although the compilation process when fine, as far as I can tell. Distro: Linux Mint 18.2 (Ubuntu 16.04), Cinnamon DE. Thanks.
So please don't replace anything and just run the backend from builddir as noted in Comment 8, this is some linker error caused by moving the binaries to another place...
Oops... I did not follow directions well. I have now retested with the patched gvfsd-trash and it worked! $ gvfs-info -a "trash::orig-path" trash:///%5Cmnt%5data%5C.Trash%5C1000%5Cfiles%5Cexample_file attributes: trash::orig-path: /mnt/data/example_path/example_file Restore worked as intended.
Thanks for testing! Attachment 362149 [details] pushed as b77ad0a - trash: Fix trash::orig-path for relative paths
Pushed to stable as well.
Thank you. Is there a relatively easy way to compile gvfsd-trash in such a way that it works as a replacement for my current bin? (without the linker errors?)
You can create symlink instead of copying, or modify exec line in /usr/share/gvfs/mounts/trash.mount file to point to your builddir executable for example.
Or you can, of course, install the custom build into system paths...
It would be best to add patch into your distro package...