Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#30061 - [glib2] gvfs-copy creates corrupted copies of files

Attached to Project: Arch Linux
Opened by Matthias Dienstbier (fs4000) - Tuesday, 29 May 2012, 16:00 GMT
Last edited by Jan de Groot (JGC) - Thursday, 31 May 2012, 13:54 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Ionut Biru (wonder)
Architecture x86_64
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


When I copy videos (probably any large files) in nautilus or with gvfs-copy some of the copies cannot be played back and differ from the original files. This does not happen with cp and I ran memtest on the machine with no errors. I assume that the root cause of the problem lies in the glib2 package probably because of the new gcc version or something like that. At this moment I cannot give more hints like last working version and it's difficult to track down as this only happens occasionally. A run in valgrind which produced corrupted copies did not show up any errors.

* package version(s)
glib2 2.32.3-1
gvfs 1.12.3-2

Steps to reproduce:

mkdir destination
gvfs-copy folder-with-videos/* destination/
diff -r folder-with-videos destination
This task depends upon

Closed by  Jan de Groot (JGC)
Thursday, 31 May 2012, 13:54 GMT
Reason for closing:  Works for me
Comment by Ionut Biru (wonder) - Tuesday, 29 May 2012, 16:50 GMT
please report this issue upstream to and paste the link here.
Comment by Matthias Dienstbier (fs4000) - Tuesday, 29 May 2012, 17:20 GMT Comment by Matthias Dienstbier (fs4000) - Wednesday, 30 May 2012, 19:06 GMT
I compiled glib2 without our CFLAGS and CXXFLAGS and could not reproduce this bug. Then I reinstalled glib2 from the repos and could not reproduce this either.

Now I think this must have been caused by the address space layout randomization of prelink. But even after running prelink again this remains irreproducible.

Sorry for the noise. I probably won't use prelink anymore and hope this will never reappear.