Thunar silently corrupts files when copying using GUI to external media.

I just tried this on a different machine and it worked OK. But it doesn't explain why Thunar in particular doesn't work on the dodgy machine.

I run dmidecode -t 2

to get motherboard info, and get

Getting SMBIOS data from sysfs. SMBIOS 2.8 present.

Handle 0x0002, DMI type 2, 15 bytes Base Board Information Manufacturer: Dell Inc. Product Name: 0C6XG5 Version: A00 Serial Number: /J57ZZ32/CN129667BP0059/ Asset Tag: Not Specified Features: Board is a hosting board Board is replaceable Location In Chassis: Not Specified Chassis Handle: 0x0003 Type: Motherboard Contained Object Handles: 0

thunar 4.18.4 on fresh install of devuan

I run "gio copy" on the funny machine and that has no issues with cmp. It very odd.

There are no obvious errors in dmesg

I am using the usb-storage and uas driver

The disk model is CT480BX500SSD1 for the internal drive.

The problem occours on multiple external drives.

Kernel is vmlinuz-6.1.0-10-amd64

I followed this https://wiki.gnome.org/Projects/gvfs/debugging and copied the file, if it's of any help.

gvfsd.log

It doesn't look too useful to me.

I install inotifytools and run inotifywait -r -m /some/path/to/externalmedia/directory and copy the file into there using the GUI.

It seems Thunar opens and closes the file being written to several times (rather than just once) and also opens the file being written to sometimes in NOWRITE mode.

I wouldn't have expected this. I would expect the file to be written to, to be opened once only, written to, and then closed once only (and preferably in the correct mode!).

inotifylog.txt

This kind of behaviour doesn't happen with cp command when I compare.

Thunar uses g_file_copy / g_file_move for file transfer, as probably all other gtk-based file-managers do. Besides that, afaik thunar does no manipulation on the file itself during copy.

What is your settings for "advanced --> use intermediate file on copy" ?

It is very severe, lots of people's files are getting destroyed.

Please no panic. Thunar 4.18.4 is now out since more than a year. If it would be a general issue, I am sure other people would already have reported so. I rather think that it is somewhat limited to your machine. Would be great if you could test with nemo/caja/nautilus/pcmanfm .. if these show the same problem, it possibly is a bug in gio/gvfs (upstream libraries).

thunar 4.18.4

Probably unrelated ... though meanwhile there is thunar 4.18.10. I suppose it would be good to have the latest bugfix releases of thunar (And as well gio, gvfs, etc. etc.) … is there a specific reason why your distro does not apply bugfixes?

dd if=/dev/urandom of=afile bs=1M count=6000

Does the size matter here? (6GB do take rather long on my system, which makes testing a pain)

I am currently short on time ... though I'll try to reproduce the problem with thunar master/4.18.4 later on.

Tested with thunar master and thunar 4.18.4, no corruption found, result of echo $? is 0 after comparison for both.

added 3. Need Info label

added 5. GVfs label

A 512M file copies OK with Thunar on this machine.
A 3000M file copies OK with Thunar on this machine.
A 4500M file does NOT copy ok with Thunar on this machine.
A 6000M file does NOT copy ok with Thunar on this machine.

The problem also occurs with Thunar 4.18.8

I tried to compile the latest Thunar, but it will be difficult as "This version of xdt-autogen (4.18.1) is too old." when running autogen.sh ... I would have to compile other bits of xfce as I understand this, and this could trash my system + I am just a user of the software, not a packager/developer.

Regarding the options advanced --> Transfer files in parallel and --> Use intermediate file on copy

both dont seem to make any difference, the file still gets corrupted w/ Thunar. I turn checksum on and the checksums fail.

With a 6000M file ...

I tested pcmanfm and it doesn't seem to have this problem on the machine (cmp comes back ok).
I tested naughtylus and it didn't seem to have the same problem either.
I tested caja and it doesn't seem to have this problem.
I tested nemo and that too seems to copy without any problems.

When I run Thunar from the CLI to copy, I get:

(thunar:14171): GLib-GIO-CRITICAL **: 18:16:56.772: GFileInfo created without standard::size

(thunar:14171): GLib-GIO-CRITICAL **: 18:16:56.772: file ../../../gio/gfileinfo.c: line 1846 (g_file_info_get_size): should not be reached

You may be able to get more info with strace:

killall Thunar thunar
strace --failed-only --decode-fds=path --follow-forks --string-limit=500 thunar
# perform the copy and see if any failures look worrisome

Does cmp report failures at the same offset each time?
Can you use /dev/zero instead of /dev/urandom to make it easier to diff the files?

When I run Thunar from the CLI to copy, I get:

(thunar:14171): GLib-GIO-CRITICAL \*\*: 18:16:56.772: GFileInfo created without standard::size

(thunar:14171): GLib-GIO-CRITICAL \*\*: 18:16:56.772: file ../../../gio/gfileinfo.c: line 1846 (g_file_info_get_size): should not be reached

Fixed by 5b61ce1f and 7686906d, released in thunar 4.18.9

I tried to compile the latest Thunar, but it will be difficult as "This version of xdt-autogen (4.18.1) is too old." when running autogen.sh ... I would have to compile other bits of xfce as I understand this

Strange to hear so, since ofc no additional requirement was added between thunar 4.18.8 and 4.18.9 … see the commit history. (xdt-autogen is part of xfce-dev-tools)

If I were able to reproduce the bug, the next thing I would do, is to directly quit thunar after the call to g_file_copy and see if that makes any difference … so that I could tell if the g_file_copy or thunar is to blame (possibly the passed flags do matter/differ between file-managers). That would require to place an exit here.

I understand that you are not a dev, and you don't want to mess with the code. Though as long as I cannot reproduce the problem, I as well won't be able to do so.

I upgraded the bios of the machine from the vendor's website and it didn't make a difference.

For the output of strace, I am getting some:

EACCES (Permission denied) errors regarding the file.

It's odd, because the permissions of the directory are

-rw-r--r-- 1 user user

and I am user: user.

I compiled thunar 4.18.9. The GLib-GIO-CRITICAL errors/warnings weren't there, but the file still didn't copy properly.

I added an exit statement where you said to and recompiled. Thunar closed after the file had copied (as expected). I then ran cmp afterwards, and the file turned out to be GOOD. I did this experiment twice to double check. As you suggested, this means it is likely something in Thunar is modifying the file after it has copied with g_file_copy and corrupting the file (at least w/ this machine).

I did some more testing of those options in preferences (because I didn't test very well the first time round :-S ) ...

I set all the options in Preferences --> Advanced --> File Transfer to "Never". This allowed me to copy the file OK/GOOD after running cmp. This is why the file turned out to be GOOD when I added the exit statement to the c file, because to reach that part of the code, I had to turn all these settings to "Never".

I set all the options in Preferences --> Advanced --> File Transfer to "Always". I do this and the GUI checksum always fail.

If I set Transfer files in parallel to "Always" and Use intermediate file on copy to "Never", then the checksum sometimes fails

I set all the options in Preferences --> Advanced --> File Transfer to "Always" EXCEPT Verify checksum on copy, which I set to "Never". This silently corrupts the file.

If I set Transfer files in parallel to "Never" and Use intermediate file on copy to "Always", then the cmp command mostly OK/GOOD but not sure about always

I wonder if Thunar is memsafe / or has been checked somehow for memory leaks? I know it's difficult, valgrind is slow ... The behaviour of sometimes erroring like that is a little erratic idk if it's possible to check.

I ran valgrind on Thunar. Thunar did not seem to have any memory leaks. I saw a lot of references to /bin/bash and wondered if /bin/bash had any memory leaks.

I think I may have found some nasty leaks in bash shell.

So the problem seems to be with Transfer files in Parallel = "Always" in combination with files >= 4500M and a flash drive (as well other gvfs locations?).

I just re-tested with thunar 4.18.4 and all FIle-transfer options enabled with multiple file-sizes up to 6000M … though still no luck to reproduce. During your test, you don't touch thunar, or? You are doing any other actions on the flashdrive in parallel?

I then ran cmp afterwards, and the file turned out to be GOOD

Thanks for testing! In case you want to further go down that road to find the malicious code, the thunar call hierarchy is thunar_transfer_job_execute --> thunar_transfer_job_copy_node --> thunar_transfer_job_copy_file --> ttj_copy_file --> thunar_g_file_copy

After the file is copied, somewhere along that call-chain, as well the files thumbnail is copied via thunar_thumbnail_cache_copy_file and a thunar_job_new_files is started to reload thunar info for the new file. Both don't look suspicious to me … though who known.

I tried copying again three times and each time it copied OK.

Things I did:

Set all options in Preferences --> Advanced --> File Transfer to "Never"
Switch to a different SHELL.

I will close the issue. Maybe can reopen if it becomes a problem again. Thanks for your help Alexander.

closed

Alright, thank you for investigations! If it should get an issue again, please feel free to reopen!

Thunar silently corrupts files when copying using GUI to external media.

Designs

Child items ...

Activity