BUG - renaming files corrupt them #99
Description
Context
ntfs-3g version: 2022.10.3 external FUSE 29 (Configuration type 7, XATTRS are on, POSIX ACLS are on)
storage device: 2TB USB HDD using ntfs
OS: Arch Linux
Problem
When I rename a file using mv I get an Input/Output Error when using ls
root@ThinkPad-server:/media/usb_2TB# ls -l | grep testfile
-rwxrwxrwx 1 root root 8738 juil. 23 2019 testfile_old.dat
root@ThinkPad-server:/media/usb_2TB# mv testfile_old.dat testfile2_old.dat
root@ThinkPad-server:/media/usb_2TB# ls -l | grep testfile
ls: cannot access 'testfile_old.dat': Input/output error
-????????? ? ? ? ? ? testfile2_old.dat
But, it works fine on newly created files:
root@ThinkPad-server:/media/usb_2TB# dd if=/dev/urandom of=testfile_new.dat bs=1M count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB, 100 MiB) copied, 1,01336 s, 103 MB/s
root@ThinkPad-server:/media/usb_2TB# mv testfile_new.dat testfile2_new.dat
root@ThinkPad-server:/media/usb_2TB# ls -l | grep testfile
ls: cannot access 'testfile_old.dat': Input/output error
-????????? ? ? ? ? ? testfile2_old.dat
-rwxrwxrwx 1 root root 104857600 janv. 30 12:09 testfile2_new.dat
debug
What would be the process to debug such issues ?
Metadata
Metadata
Assignees
Labels
No labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Participants
Activity
unsound commentedon Jan 31, 2024
@juleslagarde The main information that can be collected is from the syslog. If there's an error then there's usually one or more lines in the syslog with more information. (Depending on your distribution and setup you may find these messages in
/var/log/messages,/var/log/syslogor through invokingjournalctl -a.)juleslagarde commentedon Jan 31, 2024
here is the log of ntfs-3g in /var/log/syslog
I tried the "debug" option, and got this in the terminal:
so error code -5, probably from libntfs-3g
unsound commentedon Jan 31, 2024
That's odd, I would have expected some errors in the syslog.
So I understand that this is reproducible for files created on Windows (?) but not for files created by
ntfs-3gin Linux? Or does the problem also occur for files created byntfs-3g, although less recently (e.g. files created during a previous mount/unmount session)?Would you please post the output of
ntfsinfofor a file that is behaving in this strange way and for its parent directory, e.g. for/dev/sdb1andtestfile2_old.datin the root directory:ntfsinfo -F "/testfile2_old.dat" -v /dev/sdb1ntfsinfo -F "/" -v /dev/sdb1juleslagarde commentedon Jan 31, 2024
The files where created on Windows 4-5 years ago, yeah. And it is reproducible on theses olds files yes.
thoses lines are outputed to stderr instead of stdout:
juleslagarde commentedon Feb 1, 2024
Also the new file is still new (meaning no problem) even after umount/mount.
unsound commentedon Feb 1, 2024
It looks like the
$INDEX_ALLOCATIONattribute hits a consistency check... it seems that this attribute is never expected to be larger than 64 KiB, but in this case it's 96 KiB. I don't know what prompted the 64 KiB limit in the first place so I'll have to ask around. Just to be sure, could you possibly check this NTFS drive withchkdskin Windows and paste the output here? If the data is valid and accepted by Windows then we should reevaluate.juleslagarde commentedon Feb 1, 2024
Last time I plugged the drive on windows it removed the corrupted file.
I tried to change the windows language but couldn't arrive to a solution quickly.
Here is a Google Translate:
juleslagarde commentedon Feb 1, 2024
All issues seems to be have been fixed with
chkdsk D: /Fon windowsVery strange, thanks for your time.
unsound commentedon Feb 1, 2024
As a final comment I think what happened was that there was some inconsistency on the NTFS volume which was repaired by chkdsk. Due to other issues we weren't able to find enough information about the root cause to know exactly what it was, but whatever it was, chkdsk was able to fix it.