GNOME Bugzilla – Bug 310061
Wrong file displayed when copying multiple files
Last modified: 2005-08-29 19:58:08 UTC
Create a folder with two files, and name them "filename 1.bin" and "filename 2.txt". Make sure that "filename 1.bin" is large enough, so it looks like this: -rw-r----- 1 michael remote 734744576 2003-08-28 08:01 filename 1.bin -rw-r----- 1 michael remote 0 2005-07-11 22:03 filename 2.txt Now, in nautilus, select both of them, and copy them to a other location, you will see that "filename 2.txt" is being copied, however, since it takes so long, it HAS to be "filename 1.bin" that is really being copied. The real copying isn't affected, but it just looks ugly, and people might press cancel at the wrong moment... People notice this when they copy a few movies with subtitles, you will see that the subtitles take a long time to copy, and you don't see the real movies passing by, even tough the subtitles are only a few kb's and the movies are much larger. I'm using nautilus 2.11.4 (latest unstable).
Created attachment 48981 [details] screenshot, the files are like described in the report
Thanks for your bug report! I cannot reproduce this issue. Do you get this for all file operations, just for copies, or even just for this copy operation?
It happens with all combinations of filesizes and filenames, as long as you have a large file, followed by a small file. When i copy this combination: -rw-r----- 1 michael remote 0 2005-07-12 17:45 filename 1.txt -rw-r----- 1 michael remote 734744576 2003-08-28 08:01 filename 2.bin I can see that "filename 2.bin" takes a long time, as it should be. The same happens with moving, however, there is something strange, I moved the original combination (as in the report), it says it is moving "filename 1.bin", and if I cancel it after a few seconds, there is a file "filename 2.txt", but not a "filename 1.bin", and the original "filename 2.txt" is still in the source-folder. So, in fact, when i move these two files, and I cancel after say 2 seconds, when it is still moving the large file, the small file is already copied, but it isn't removed... This also happens when the small file isn't empty.
I can confirm this bug in nautilus 2.10.1 and here is a different testcase from which I hit this bug: nelson@gnelson ~ $ mkdir testcase && cd testcase nelson@gnelson ~/testcase $ echo "hola" > hola.txt nelson@gnelson ~/testcase $ echo "foo" > uncopiable.txt nelson@gnelson ~/testcase $ chmod a-r uncopiable.txt nelson@gnelson ~/testcase $ ls -l total 8 -rw-r--r-- 1 nelson users 5 ago 22 11:58 hola.txt --w------- 1 nelson users 4 ago 22 11:59 uncopiable.txt nelson@gnelson ~/testcase $ Now open nautilus and copy the *testcase folder* and paste it in anyplace, an error dialog will appear saying the file "hola.txt" cannot be copied because it's not readable, which is wrong. Now enter the *testcase folder* and copy the two files and paste it anyplace, now the error dialog will say the file that cannot be copied is uncopiable.txt, which is right. Now is up to people using HEAD to check if they can reproduce it with new testcase.
Thanks for giving us this sample. I can reproduce this.
This is actually a gnome-vfs issue.
Created attachment 51120 [details] [review] gnomevfs-copy verbosity patch This patch makes gnomevfs-copy more verbose on failure.
Created attachment 51122 [details] bash script to do what's described in comment 4 using gnomevfs-copy Note that the progress_cb is obviously invoked with "hula.txt" where it should be invoked with "uncopiable.txt"
Created attachment 51129 [details] [review] Proposed patch (untested) GnomeVFS did't like me the last couple of hours. Maybe sb. from you could test it? I'm pretty much sure I found the cuplrit.
I've applied the patch and works very well. Thanks Christian.
Looks fine to me
Committed. Closing.
Thanks for your efforts Michaël and Nelson btw!
Just setting the patch status to commited to get it of my patches bugzilla query.