NTFS3 in Kernel 6.9.0-1 - still corrupting my files

Support
1

Continuing the discussion from Re: Ntfs3 keeps corrupting my ntfs partitons:

As Manjaro has progressed to Linux 6.9.0-1 kernel, the NTFS support is solely relying on NTFS3, instead of the good old NTFS-3G.

And while everyone has been singing praise about improved file transfer performance, I would like to share my painful experience which just happened 10 mins ago.

I transferred 1TB of data from EXT4 partition to NTFS partition, done without problem.
Then, I performed rename function on 12 text files, total file size 1MB or lesser, using KRename.
Upon execution:"

  1. 8 out of the 12 text files in the rename operation, disappeared from the folder.
  2. 10 other files in the same folder, totalling 65GB, not involved in the rename operation, also disappeared.

ntfsfix using console has been denied - because NTFS3 determined that

“Refusing to operate on read-write mounted device /dev/sda1”

So it seems like NTFS3 has never tackle this bug, and files just keep disappearing.

2

No matter the attemps to access NTFS - the filesystem is still propietary - and thereby reverse engineered.

Not a bug - do not use NTFS for anything important - it is not native to Linux - and completely unsupported

3 Likes
3

LTS Kernel 6.1 still use NTFS-3G or you can use a exfat partition to transfer files later to your NTFS Partition, if you really want to rely on NTFS.

4

the NTFS-3G has no issue.
I cannot understand the logic to change to NTFS3 that has inferior stability and bug, as compared to NTFS-3G.

5

You do not have to …

We do not have to … it is all upstream kernel - we all have to adapt …

and no matter what you think - ntfs is reverse engineered …

3 Likes
6

I think this “decision” of the tool is a quite prudent one.
Trying to work on/repair a mounted file system is never a good idea.

3 Likes
7

Please explain what the intention was in attempting to use ntfsfix.

What is it (to the extent of your understanding) that ntfsfix can possibly do to repair an NTFS volume?

1 Like
8

Checking file system on F:
Volume label is XXXX.
Examining 3 corruption records …

Record 1 of 3: Corruption in index “$I30” of directory “\XXXX <0x1,0x7b>” … corruption found and fixed.

Record 2 of 3: Index “$I30” of directory “\XXXX<0x1,0x7b>” is mis-ordered …
The down pointer of current index entry with length 0x18 is invalid.
00 00 00 00 00 00 00 00 18 00 00 00 03 00 00 00 …
ff ff ff ff ff ff ff ff ?? ?? ?? ?? ?? ?? ?? ?? ÿÿÿÿÿÿÿÿ…
corruption found and fixed.

Record 3 of 3: Missing 36 entries in index “$I30” of directory “\XXXX <0x1,0x7b>” … corruption found and fixed.

3 corruption records processed in 0.1 seconds.
Windows has fixed all previously identified issues with this drive.
No further action is required.

The corruption caused by NTFS3, fixed.
So we are embracing NTFS3 which caused corruption, so that we can go back to Windows to fix it?
Let me repeat: NTFS-3G does not cause corruption.

9

It’s weird how it works, I had issues with NTFS-3G and was an early adopter of NTFS3, I have no issues with it (but use it only rarely I have to admit). In any case, you should report NTFS3 issue to upstream if something needs to be fixed.

10

Could you please answer the question asked?

11

This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.