GNOME Bugzilla – Bug 673598
Wrong filename when restoring from Trash
Last modified: 2012-11-30 22:59:21 UTC
Original report in Launchpad, reproduced and confirmed. In this particular scenario, the filename is wrong when restoring a file from Trash. Here is the exact scenario, that I am able to reproduce 100% of the time on Ubuntu 12.04 and 10.04 (it probably affects all Ubuntu versions) : 1. Put 2 files (their content can be identical or different) with the same name in 2 different directories : mkdir ~/test1 mkdir ~/test2 cp installation_manual.pdf test1/doc.pdf cp report.pdf test2/doc.pdf 2. Open Nautilus ; go to the "test1" directory and delete the file "doc.pdf". Go to the "test2" directory and delete the file "doc.pdf". 3. In the Trash directory, you now have : % ls -l ~/.local/share/Trash/files/ total 19M -rw-r--r-- 1 alexis alexis 758K avril 5 14:29 doc.2.pdf -rw-r--r-- 1 alexis alexis 18M avril 5 14:29 doc.pdf % ls -l ~/.local/share/Trash/info total 8,0K -rw-rw-r-- 1 alexis alexis 82 avril 5 14:30 doc.2.pdf.trashinfo -rw-rw-r-- 1 alexis alexis 82 avril 5 14:30 doc.pdf.trashinfo % cat ~/.local/share/Trash/info/doc.pdf.trashinfo [Trash Info] Path=/home/alexis/test1/doc.pdf DeletionDate=2012-04-05T14:30:02 % cat ~/.local/share/Trash/info/doc.2.pdf.trashinfo [Trash Info] Path=/home/alexis/test2/doc.pdf DeletionDate=2012-04-05T14:30:07 As you can see, the file "doc.pdf" from the "test2" directory is renamed "doc.2.pdf" in the Trash directory, but it's related "trashinfo" file has the right filename "doc.pdf" in the "Path" variable. 4. In Nautilus, go to the Trash, select the 2 files and clic on "Restore". 5. Now look at the names of the restored files : % ls -l ~/test1/ total 18M -rw-r--r-- 1 alexis alexis 18M avril 5 14:29 doc.pdf % ls -l ~/test2/ total 760K -rw-r--r-- 1 alexis alexis 758K avril 5 14:29 doc.2.pdf As you can see, the file restored in the "test2" directory has a filename "doc.2.pdf" instead of "doc.pdf".
The problem is with the code in libnautilus-private/nautilius-file-utilities.c the function nautilus_restore_files_from_trash() uses nautilus_file_operations_move() This moves the files from the trash directory back to the path stored in Trash Info by passing a destination directory. The problem is there is no destination filenames given so they end up with the filename used when they were in the trash directory rather than the original filename.
Created attachment 229748 [details] [review] Make sure to use correct filename when restoring from trash This patch makes sure file are restored with the correct filenames. This patch is for Git master but has only been tested so far on 3.4.2. Running the tests as in comment 1 Nautilus (3.4.2) is giving a warning: ** (nautilus:16101): WARNING **: Error getting info: Error when getting information for file '/home/timothy/test_nautilus/test2/attend_record_tim.2.pdf': No such file or directory
Ok, the warning seems to be limited to the 3.4 the affected code has changed since 3.6 so the warning is no longer an issue. Would be good to get this reviewed.
Review of attachment 229748 [details] [review]: Thanks, I added some comments below. ::: libnautilus-private/nautilus-file-operations.c @@ +3245,3 @@ GFile *dest; GFileInfo *info; + char *copyname, *trash_orig_path; The idea of the patch is good; you should pass G_FILE_ATTRIBUTE_TRASH_ORIG_PATH to g_file_query_info() above, and I would also check for g_file_has_uri_scheme(src, "trash") before trying to use it. @@ +3264,2 @@ if (info) { + trash_orig_path = g_strdup (g_file_info_get_attribute_byte_string (info, G_FILE_ATTRIBUTE_TRASH_ORIG_PATH)); I would refactor this code differently, like (pseudocode) copyname = NULL; if (g_file_has_uri_scheme (src, "trash")) { copyname = get trash orig path } if (copyname == NULL) { copyname = get copy name; } dest = make_file_name_valid (dest_dir, copyname)
Created attachment 230157 [details] [review] Make sure to use correct filename when restoring from trash Thanks for the review the updated patch is much cleaner thanks to your suggestions. I've also added a comment as its not immediately clear why we would be doing this inside this function.
Review of attachment 230157 [details] [review]: Thanks, this looks good!
Excellent. Can someone with git access please push this as I don't have access.
Pushed, thanks!