GNOME Bugzilla – Bug 145487
Data lost if moving a file in a subdirectory fails
Last modified: 2004-12-22 21:47:04 UTC
To easily demonstrate this bug, I have to use the bug: http://bugs.gnome.org/show_bug.cgi?id=145486 At a shell: $ mkdir dest $ mkdir test $ cd test $ echo hello > test?me $ echo hello > test.me From Nautilus, try to move the directory 'test' into 'dest'. Nautilus will state that it could not copy the 'test?me' file, and will offer to Skip, Retry or Cancel. If the user selects Skip, Nautilus will not copy the 'test?me', but will still remove the 'test' directory. Expected results: dest/test/test.me test/test?me Results we get: dest/test/test.me Basically, test?me has been lost. While I have used bug 145486 in my example, data loss will occur whenever Nautilus fails to move a file within a sub- directory and the user selects Skip. This is because Nautilus will still delete the sub-directory. I suggest that Nautilus checks that any directory to be removed because of a move operations is empty before doing so. Am using the current Debian packages from unstable on x86. I believe it's Nautilus 2.6.3-1.
Created attachment 29270 [details] Snapshot of error message.
I'm updating my report now that I am at the Linux box and not the Windows box. Turns out that copying a file with a ? in the name to a FAT partition will fail. For me /share is a a FAT partition, and this is where I noticed the bug. The following shell session demonstrates what I see: harvey@samwise:~$ nautilus --version Gnome nautilus 2.6.3 harvey@samwise:~$ mkdir test harvey@samwise:~$ echo hello > 'test/test?me' harvey@samwise:~$ echo hello > 'test/test.me' harvey@samwise:~$ ls -l test total 8 -rw-r--r-- 1 harvey harvey 6 2004-07-06 21:10 test?me -rw-r--r-- 1 harvey harvey 6 2004-07-06 21:10 test.me At this point, I use Nautilus to move the directory 'test' to '/share'. I get one error (attached). After pressing 'Skip' the directory is supposedly moved. I now do the following at a prompt: harvey@samwise:~$ ls -l /share/test total 4 -rwxrwxrwx 1 root root 6 2004-07-06 21:10 test.me harvey@samwise:~$ ls -l test ls: test: No such file or directory And we have data loss! Note that this bug is sensitive to the order in which the files are created. If I create the file with the ? in it's name second, there is no data loss.
Have tracked down what I think is the location of the bug - in gnome-vfs. Had to track it all the way from the Nautilus functions through to GnomeVFS. In the rename_helper function in the file module (gnome-vfs/modules/file-method.c) the rmdir function is used without first checking that the directory is empty. If a file within a directory is skipped during a move (made possible by Nautilus callbacks), the directory is non-empty and should not be deleted. Why the order of the files in the directory matters I do not know. This is most likely something to do with the complicated logic in many of the functions, especially those involving loops. My gut instinct is that a flag variable hasn't been reset somewhere inside a loop. Or a flag variable is overwritten. Anyway, a simple fix is for the file method in GnomeVFS to check if a directory is empty before removing it in the rename_helper. Will try to move this bug to the GnomeVFS buglist instead.
Fixed in HEAD: 2004-07-13 Alexander Larsson <alexl@redhat.com> * libgnomevfs/gnome-vfs-xfer.c (copy_items): Make sure to not lose skip if its ever set to true. Fixes bug #145487 We should probably get this in on gnome-2-6 too.
I committed it to the gnome-2-6 branch, closing the bug.