GNOME Bugzilla – Bug 530094
Nautilus (gio/gnomevfs) performs unneccessary copying of sparse files
Last modified: 2018-05-24 11:24:21 UTC
NOTE: I'm on ubuntu 8.04, gnome 2.22 so I assume nautilus is using GIO. When nautilus (or rather, the underlying mechanism - gio/gnomevfs) is copying a sparse file (http://en.wikipedia.org/wiki/Sparse_file), the resulting copy will be as large as the file size of the original file - even if the original file didn't actually use all those blocks. (confusing I know, but see below what I mean :) This makes the copy procedure unneccessary long if the diff between allocated block size and file size is big. At least Azureus uses sparse files while downloading torrents. But wikipedia suggests its also commonly used for databases, log files and scientific apps. For an almost empty file (few blocks allocated, ~a few kb) with a size of 350MB the difference is quite noticable: $ time cp my-sparse-file my-copy real 0m0.930s user 0m0.112s sys 0m0.764s $ time gnomevfs-copy my-sparse-file my-copy-2 real 0m6.874s user 0m0.148s sys 0m2.712s Procedure to reproduce: $ cd /tmp $ dd if=/dev/zero of=my-sparse-file count=1 bs=1 seek=1M $ ls -lsh my-sparse-file 8,0K -rw-r--r-- 1 isak isak 1,1M 2008-04-26 19:23 my-sparse-file $ cp my-sparse-file copy-using-cp $ (do copy in nautilus or using: gnomevfs-copy my-sparse-file copy-using-nautilus) $ ls -lsh total 1,1M 0 -rw-r--r-- 1 isak isak 1,1M 2008-04-26 19:33 copy-using-cp 1,1M -rw-r--r-- 1 isak isak 1,1M 2008-04-26 19:33 copy-using-nautilus 8,0K -rw-r--r-- 1 isak isak 1,1M 2008-04-26 19:23 my-sparse-file
Please note that GIO and GnomeVFS are two completely different things. GIO uses GVfs for protocol implementations, and Nautilus uses GIO for its file transfers. So maybe you want to redo the tests with gvfs-copy instead of gnomevfs-copy.
Yes, I know they are different. I did not find any gvfs-copy command in ubuntu so I just assumed the old binaries used gio. In any case, the reason I filed this bug is because I saw the issue in nautilus when copying files. So, assuming nautilus 2.22 in Ubuntu Hardy uses GIO, it looks like this bug applies to both gio and gnomevfs. I'll redo the tests with the binaries you suggested and post the result here.
Be sure you have gvfs-bin installed in Ubuntu/Debian, that's where the gvfs-* utilities are currently stashed away.
Ok, redid the tests using gvfs-copy from the gvfs-bin package and the results are the same: isak@skywalker:/tmp/naut$ ls -lsh totalt 1,1M 0 -rw-r--r-- 1 isak isak 1,1M 2008-04-30 22:14 copy-using-cp 1,1M -rw-r--r-- 1 isak isak 1,1M 2008-04-30 22:15 copy-using-gvfs 8,0K -rw-r--r-- 1 isak isak 1,1M 2008-04-30 22:14 my-sparse-file I also upped the size to 500Mb and redid the timing (I did the copy using 'cp' first, so any unfair benefit from disk caching was given to gvfs-copy): $ time cp my-sparse-file copy-using-cp real 0m3.029s user 0m0.232s sys 0m1.460s $ time gvfs-copy my-sparse-file copy-using-gvfs real 0m18.154s user 0m0.064s sys 0m4.376s
This has been reported in Debian as Bug#474152 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=474152 I can confirm this for 2.20.0 and 2.22.2
This is probably a bug in GIO itself, not in nautilus; the latter merely calls g_file_copy* functions.
Reassign. The test case clearly shows that it's not working using gvfs-copy which uses GIO to copy files. I reproduced this with glib 2.28.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/136.