You are not logged in.
Pages: 1
After copying a zip file of 500mb from one user to another user with thunar, both home directories being on the same ext4 filesystem on the same magnetic disk, I noticed that the destination zip file could not be extracted because of a crc error reported by the engrampa archive manager. So, I checked the source of the copy, which could be extracted. md5sum showed different hashes for both files.
I assume that the copying process was finished because the corresponding "thunar - file operation in progress" window was already closed. I did not run lsof.
I had to kill thunar later because it was not reacting and there was a segfault visible in dmesg.
After killing thunar, the destination file was OK. I could not reproduce the error ever again.
How do you think about these possible causes?
(a) A read error on the disk. This should be ruled out because magnetic disks store data encoded. In case a sector can not be retrieved, the disk would cause an i/o error instead of returning false data. An error concerning the disk is not visible in dmesg.
(b) Data corruption occuring on the sata interface. I would rule this one out, because it would be detected and there are no errors concerning the disk's sata interface visible in dmesg.
(c) Faulty memory. Perhaps, when the file appeared with data corruption, it was not read from disk, but from the cache, and the memory returned corrupt data. I have quality non-ecc ram (kingston) where no error can be exposed in memtest86. However, it is possible that there was a memory error, but I could run memtest86 until the sun explodes and never encounter an error again.
(d) Thunar encountered a bug where it masked the correct file. Upon killing thunar, the file was ok.
(e) Maybe, it is not safe to assume that Thunar has finished the copy process when the window "file operation in progress" disappears.
How can I investigate why the destination file appeared with wrong data?
----------------------------------
the error occured on mar 10th, when the system was up-to-date.
Name : thunar
Version : 4.16.5-1
Description : Modern file manager for Xfce
Architecture : x86_64
URL : https://docs.xfce.org/xfce/thunar/start
Licenses : GPL2 LGPL2.1
Groups : xfce4
Provides : None
Depends On : desktop-file-utils libexif hicolor-icon-theme libnotify libgudev exo libxfce4util libxfce4ui libpng
Optional Deps : gvfs: trash support, mounting with udisk and remote filesystems [installed]
tumbler: thumbnail previews [installed]
thunar-volman: removable device management [installed]
thunar-archive-plugin: archive creation and extraction [installed]
thunar-media-tags-plugin: view/edit ID3/OGG tags
Required By : thunar-archive-plugin thunar-volman xfdesktop
Optional For : None
Conflicts With : None
Replaces : None
Installed Size : 6,32 MiB
Packager : Evangelos Foutras <foutrelis@archlinux.org>
Build Date : 2021-03-08T10:07:26 CET
Install Date : 2021-03-08T11:06:10 CET
Install Reason : Explicitly installed
Install Script : No
Validated By : Signature[Wed Mar 10 11:44:05 2021] pool-thunar[14906]: segfault at 0 ip 0000000000000000 sp 00007fc3b3ffda98 error 14 in thunar[55d3bbe21000+22000]
[Wed Mar 10 11:44:05 2021] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6.
[Wed Mar 10 11:44:05 2021] audit: type=1701 audit(1615373046.899:750): auid=1000 uid=1000 gid=1000 ses=1 pid=14784 comm="pool-thunar" exe="/usr/bin/thunar" sig=11 res=1(there are usernames in dmesg, so I can not share the whole output)
Last edited by lt.daniel (2021-03-30 00:11:15)
Offline
(e) Maybe, it is not safe to assume that Thunar has finished the copy process when the window "file operation in progress" disappears.
This is almost certainly a flawed assumption. Were both file-systems unmounted cleanly on shutdown?
[Wed Mar 10 11:44:05 2021] pool-thunar[14906]: segfault at 0 ip 0000000000000000 sp 00007fc3b3ffda98 error 14 in thunar[55d3bbe21000+22000] [Wed Mar 10 11:44:05 2021] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. [Wed Mar 10 11:44:05 2021] audit: type=1701 audit(1615373046.899:750): auid=1000 uid=1000 gid=1000 ses=1 pid=14784 comm="pool-thunar" exe="/usr/bin/thunar" sig=11 res=1(there are usernames in dmesg, so I can not share the whole output)
You can dump the journal to a file then replace what you do not want to share with redacted replacements e.g. redacted001.
Offline
Pages: 1