GNOME Bugzilla – Bug 403652
Canceled-Copy should not left incomplete files
Last modified: 2021-06-18 15:51:53 UTC
When the copying of a file is interrupted (by the user or by some error) an incomplete file is left of the target device. It is not possible to detect that this file is corrupted at first glance. Maybe it would be wiser to give the target file a temporary name (like foobar.ext.copying) and rename it after completion. So it would be easy to spot incomplete files, when copying the interupted folder again auto-skip would not skip the incomplete file and other applications wouldn't be able to access the file. Furthermore nautilus should try to remove the partial file when the copying is canceled by the user (or if possible, when it is canceled because of an error).
*** Bug 693528 has been marked as a duplicate of this bug. ***
Created attachment 243594 [details] [review] Fixes this bug. This patch appends "_unfinished" to URI of files being copied/moved. Once copied the file is renamed back to its original name. This change is not done in case of overwrite operation. Also, in case of error/cancel, the incomplete file is deleted.
Any news on this bug?
Review of attachment 243594 [details] [review]: Works fine. Tested on the upstream branch and on Nautilus 3.8.X.
Created attachment 264843 [details] [review] Cancel Paste Operation This is M S SURAJ patch with slight modifications: - add a better title - integrate M S SURAJ message as commit message - remove 4 useless spaces - rename patch file
Thanks for the patch, sorry for so late review, I'm discussing this approach with designers.
Review of attachment 264843 [details] [review]: Hey, thanks for the work on this! However I think this is the wrong approach. The problem with this is that display name actually renames the file too, which makes me afraid it's going to introduce corner cases where this can fail more than it worth. For example, changing the display name actually triggers a changed signal in the nautilus cache, which in the end is connected to all the views of nautilus. That can cause the operation confuse what was the real file that was being operated. The right approach it's to filter the files that are currently in an operation, and display some different widget, rather than modifying the actual filesystem. For that, we need the operations rework, so it's not doable right now. But we have planned to have it done for the next year.
Review of attachment 243594 [details] [review]: rejected similarly to the previous one
Any progress? This issue is not solved in nautilus 3.26 beta.
duplicate https://bugzilla.gnome.org/show_bug.cgi?id=389828
*** Bug 389828 has been marked as a duplicate of this bug. ***
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of Files (nautilus), then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/nautilus/-/issues/ Thank you for your understanding and your help.