After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 145487 - Data lost if moving a file in a subdirectory fails
Data lost if moving a file in a subdirectory fails
Status: RESOLVED FIXED
Product: gnome-vfs
Classification: Deprecated
Component: Module: file
2.6.x
Other Linux
: Normal critical
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
Depends on:
Blocks:
 
 
Reported: 2004-07-06 03:39 UTC by pah06
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Snapshot of error message. (12.00 KB, image/png)
2004-07-06 11:16 UTC, pah06
Details

Description pah06 2004-07-06 03:39:03 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.
Comment 1 pah06 2004-07-06 11:16:03 UTC
Created attachment 29270 [details]
Snapshot of error message.
Comment 2 pah06 2004-07-06 11:16:45 UTC
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.
Comment 3 pah06 2004-07-07 23:59:38 UTC
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.
Comment 4 Alexander Larsson 2004-07-13 13:49:24 UTC
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.
Comment 5 Christophe Fergeau 2004-07-20 20:08:30 UTC
I committed it to the gnome-2-6 branch, closing the bug.