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 310061 - Wrong file displayed when copying multiple files
Wrong file displayed when copying multiple files
Status: RESOLVED FIXED
Product: gnome-vfs
Classification: Deprecated
Component: File operations
2.11.x
Other All
: Urgent major
: ---
Assigned To: gnome-vfs maintainers
Nautilus Maintainers
Depends on:
Blocks:
 
 
Reported: 2005-07-11 20:15 UTC by Michaël Arnauts
Modified: 2005-08-29 19:58 UTC
See Also:
GNOME target: ---
GNOME version: 2.11/2.12


Attachments
screenshot, the files are like described in the report (12.48 KB, image/png)
2005-07-11 20:15 UTC, Michaël Arnauts
  Details
gnomevfs-copy verbosity patch (1.02 KB, patch)
2005-08-22 14:42 UTC, Christian Neumair
none Details | Review
bash script to do what's described in comment 4 using gnomevfs-copy (269 bytes, text/plain)
2005-08-22 14:45 UTC, Christian Neumair
  Details
Proposed patch (untested) (817 bytes, patch)
2005-08-22 15:58 UTC, Christian Neumair
committed Details | Review

Description Michaël Arnauts 2005-07-11 20:15:24 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).
Comment 1 Michaël Arnauts 2005-07-11 20:15:51 UTC
Created attachment 48981 [details]
screenshot, the files are like described in the report
Comment 2 Christian Neumair 2005-07-12 14:44:30 UTC
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?
Comment 3 Michaël Arnauts 2005-07-12 15:55:43 UTC
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.
Comment 4 Nelson Benitez 2005-08-22 13:13:04 UTC
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.
Comment 5 Christian Neumair 2005-08-22 14:20:51 UTC
Thanks for giving us this sample. I can reproduce this.
Comment 6 Christian Neumair 2005-08-22 14:40:00 UTC
This is actually a gnome-vfs issue.
Comment 7 Christian Neumair 2005-08-22 14:42:02 UTC
Created attachment 51120 [details] [review]
gnomevfs-copy verbosity patch

This patch makes gnomevfs-copy more verbose on failure.
Comment 8 Christian Neumair 2005-08-22 14:45:57 UTC
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"
Comment 9 Christian Neumair 2005-08-22 15:58:54 UTC
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.
Comment 10 Nelson Benitez 2005-08-23 18:02:55 UTC
I've applied the patch and works very well. Thanks Christian.
Comment 11 Christian Kellner 2005-08-29 18:58:23 UTC
Looks fine to me
Comment 12 Christian Neumair 2005-08-29 19:39:55 UTC
Committed. Closing.
Comment 13 Christian Neumair 2005-08-29 19:40:31 UTC
Thanks for your efforts Michaël and Nelson btw!
Comment 14 Christian Kellner 2005-08-29 19:58:08 UTC
Just setting the patch status to commited to get it of my patches bugzilla query.