If an error occurs while moving files across disk volumes, Nautilus leaves duplicate files on source and target

[Rocko]

If you try to move a number of files from one file system to another and an error occurs that causes Nautilus to abort the move (eg disk full), it leaves duplicate files on both source and target.

Personally, I would prefer it if Nautilus treated the move as a number of individual file move operations (ie if it removed each source file once the file has been successfully copied to the target).

But if Nautilus is treating the entire move as one operation it should probably (try to) delete target files on an error, so that you don't end up in an 'indeterminate state' with a partial duplication of the source on the target. (This is especially a problem if you are moving a lot of files into a directory already containing a lot of files as it's very difficult to ascertain which ones copied and which ones didn't.)

[Sebastien Bacher (seb128)]

Thank you for your bug. What version of Ubuntu do you use. Does it remove files from the source directory when you face that case? If not that's probably a duplicate of bug #67691 you opened before that one

[Rocko (rockorequin)]

I am using 6.10 (and it happens in 6.06 as well).

I think this is broader than 67691.

The source files are not deleted if there is an error. So, for example, if you try to move 100 files and the operation fails while file 90 is being moved, you will now have:

* 100 complete files still on the source
* 89 complete files (copies) on the target
* 1 partial copy of file 90 on the target (which is what I described in 67691).

So the annoying thing is that now you have to check very carefully which files were copied (it is safer to delete the target and then try to do the move again).

If each file were moved individually, you would only have 11 files on the source (files 90-100), 89 complete (moved) files on the target, and the partially copied file 90 on the target.

I think 67691 is a more severe problem because it can create the impression that there is a complete copy of file 90 on the target.

[Removed by request (removed1836289)]

Confirmed, still happens in 2.22

[Rocko (rockorequin)]

Actually, I think this is actually fixed in Hardy/gnome 2.22 - the "multiple file move" behaviour I've observed in Hardy is that each file is deleted as soon as it is successfully copied to the target, so in the scenario I originally outlined, files 1-89 would disappear from the source. File 90 would probably still be partially copied on the target, which is bug 67691.

[Sebastien Bacher (seb128)]

thank you for the update, closing the bug since that works on hardy