NTFS3 is corrupting data?
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 141
- Forks
- 146
- Avg merge
- 11h 7m
- Merged PRs (30d)
- 407
Description
Summary:
Could you please investigate NTFS3 kernel module?
About after Solus 4.4 upgrade, I'm experiencing 2 issues with NTFS partitions:
- Copying files from EXT4 to NTFS partition, they just disappear after copy process.
- The system is unable to mount NTFS partitions right after a couple of minutes was mounted.
Steps to reproduce:
Events are sporadic. No visible reasons. Using Nemo file manager.
For case 1:
- Select group of files (count between 80 and 100 images)
- Copy from EXT4 partition
- Paste into NTFS partition
- After the copy process ends, files disappear instantly (the event can be observed)
For case 2:
- Mount NTFS partition
- Browse folders
- Copy TO and FROM files
- Unmount partition
- Do some other work
- Mount the same partition again
- The system is reporting:
wrong fs type, bad option, bad superblock on /dev/sdc5, missing codepage or helper program, or other error
System details:
Solus 4.5 Budgie
Kernel Version: 6.8.9-289.current (64-bit)
Other comments
Many people in other distros are complaining like me from NTFS3, which by their assessment isn't managing correctly the file system and causing data lose. NTFS3 is flagging hard drives and their partitions frantically with "Dirty flags", without proper report of the condition. The only thing that recommends is to be used "chkdsk" of Windows.
There is a bug found in the code of NTFS3 at 2022, which causes a crash of the ntfs3 driver itself, if compiled directly to the kernel, it crashes the whole system.
Reference to the article of the bug
Reference to the bug report
There could be more bugs since the driver is not maintained by the owner, according to users and devs.
Notes and temporary solution:
For case 1:
After the files disappear and the folder is empty (or is left only with previously resident files).
Terminal doesn't show anything, no hidden files also, the folder properties shows zero size (except the previously located files).
But If I create a simple text file, named (with extension) like one of the missing files, the system is saying: "there is already file with the same name".
My guess is that the files are indexed wrongly during the copy to NTFS and this causes the disappearance.
Connecting the HDD to Windows, Repairing Tools, Fixing the errors and files pop-up.
After a couple of days other stack of files during copy process are vanishing. It doesn't follow obvious pattern.
For case 2:
At first I thought that I have bad sectors, but this happened to: 2 internal HDD Seagate, 1 external HDD Samsung, 1 USB flash drive for multiple times.
I don't think they broke all together or fall in bad sectors synchronized. Windows is opening the drives without alerts.
While repairing with Tools it states errors and fixes them, then the drives pop-up in Linux.
One additional note:
I have created and formated under Solus new empty NTFS partition and relocated some data. Windows - in it's turn, saw nothing inside.
The partition was empty. Checking the properties, disk space chart was showing presence of something in a couple of GB, but the partition was empty.
Using "chkdsk" didn't found any errors. Back in linux, partition was unable to mount: "wrong fs type..."
Never had such issues before with Solus, it was very stable.
Trying to investigate, checking condition:
- Completely wipped HDD with zeros
- Checked for bad sectors and condition with "chkdsk /f /r" under Windows and dedicated Seagate Tools
- Split in two partitions
- Clean install of Solus 4.5 Budgie on one of the partitions
- Freshly formated NTFS under Windows on the other
- Solus unable to mount it: "wrong fs type, bad option..."
While ntfsfix is sayng:
sudo ntfsfix --no-action /dev/sda5
Mounting volume... OK
Processing of $MFT and $MFTMirr completed successfully.
Checking the alternate boot sector... OK
NTFS volume version is 3.1.
NTFS partition /dev/sda5 was processed successfully.
dmesg is sayng:
dmesg | grep sda5
sda5: It is recommened to use chkdsk.
ntfs3: sda5: volume is dirty and "force" flag is not set!
When manually mounting and unmounting the partition it is successful with no complains:
sudo mount /dev/sda5 /mount/media`
Blacklisting ntfs3 mounting is not successful:
I have created file: /etc/modprobe.d/disable-ntfs3.conf with content: blacklist ntfs3
dmesg is saying:
request_module fs-ntfs3 succeeded, but still no fs?
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No repository file, test, or entry point is identified. Start by reviewing the reported Solus 4.5 and kernel 6.8.9-289.current environment, then reproduce the NTFS copy, unmount, and remount cases while collecting dmesg output. Done requires a confirmed cause and a verified fix for the disappearing files or mount failures.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- linux
- Domain
- operating-systems
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 15/100