GNOME Bugzilla – Bug 330568
Renaming a folder while Nautilus is copying to it breaks the transfer
Last modified: 2021-06-18 15:16:19 UTC
Please describe the problem: Please... before you mark this as NOTABUG because it's probably the same as how Windows works, just think about it. Steps to reproduce: 1. Copy a large folder full of lots of files to another 2. Rename the destination folder before the transfer completes Actual results: Error "File not found" while copying "filename". Would you like to continue? Expected results: Folder copy to resume in new destination folder. Does this happen every time? Yes. Other information: There are probably tens of technical solutions to this. One way, you could use gamin to monitor what is happening and adjust the destination directory accordingly. Another way you could lock the folder from being moved/renamed while a file transfer is in place. Another way you could have some underlying library pass a handle to the destination folder vs. just copying to it by name. I will post something else later that might be of interest. ♥ GNOME 2.16 ♥
See also: http://bugzilla.gnome.org/show_bug.cgi?id=330572
Thanks for your bug report! The big problem with your monitoring proposal is that it can make file transfers actually more fragile than robust, because the monitoring backend might for instance emit a stale event, and modifying the target wouldn't be a good idea in that case. There may be a possibility for local files to use a file handle, instead of using textual URIs once the target directories where investigated. However, ensuring that this will work correctly for all subdirectories means having zillions of file handles open which is not what we want. The semi-ASCII heart artwork is really nice btw. :)
Is there actually any need to copy in-place, anyway? From what I can gather, doing so just seems to mess with Beagle and Rhythmbox because of the huge number of file monitoring changes that occur. Why not make the thing appear to be atomic. When copying hundreds of MB across hundreds of files, it would probably be more desirable to do the actual file copying into /tmp, then move the files into the target when done. Would any harm come of this?
Ubuntu bug about that: https://launchpad.net/products/nautilus/+bug/59230
*** Bug 336639 has been marked as a duplicate of this bug. ***
*** Bug 554499 has been marked as a duplicate of this bug. ***
I can reproduce on version 3.6 The file being copied at the time of destination renaming completes the copy successfully, but when nautilus tries to copy the next file, this dialog pops up: > . > / \ Error while copying “foo”. > / ! \ > /_____\ There was an error copying the file into %DESTINATION_BEFORE_RENAME. > > [-] Show more details > > Error opening file '%DESTINATION_BEFORE_RENAMING/foo': No such > file or directory > > [ Cancel ] [ Skip All ] [ Skip ]
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.