@phlim can you elaborate a bit on that, what exactly was fixed?
I noticed it because now I can rw mount an NTFS veracrypt container (fuse ntfs-3g) again with linux68. Before only as read-only.
This was one of the reasons why I blacklisted NTFS3 as well.
And the main reason was that when using NTFS3, data corruption happened, which caused me to lose GB of data, and there was no way to recover the lost data.
I have been using qBT on NTFS partition, and I can vet that the damage is related to NTFS3 and not NTFS-3G.
Finally the good news!
Though in frustration over the exclusion of NTFS-3G in earlier kernel, I have converted 50% of my HDDs to EXT4.
The NTFS3 kernel prevents NTFS volumes from mounting if it detects the so-called dirty bit (a flag that is triggerred when possible damage is found). When that happens, an associated error message is typically displayed BAD SUPERBLOCK etc.
Let me be clear: NTFS3 does not cause the damage (corruption) that the error indicates - it simply tells you that it exists. This is something NTFS-3G does not do - itâs incapable - so, if damage exists, it does not tell you (no error), and the user continues using the volume while oblivious to there being any damage.
So, when using NTFS-3G, the reason for so many uninformed comments such as âIt doesnât happen with ntfs-3gâ is simply that it doesnât tell the user that a problem exists.
When using NTFS3, all that people will understand is that there is an error, and ântfs3 wonât let me mount my ntfs volumeâ or ântfs3 has corrupted my ntfs volumeâ, in the majority of cases, falls back to a lack of understanding that these errors are actually a good thing.
You might find this interesting:
The only way to safely recover data on an NTFS volume, is with Windows based tools, in a Windows environment. Period.
In this instance, you can likely blame yourself. As stated earlier:
In fact, itâs not recommended at all. There will be little to support that claim, but remember, software isnât generally written with a multiboot scenario, or using foreign filesystems in mind. The Windows qBit version is obviously better suited (by design) for use with NTFS, but as also previously mentioned, even the Microsoft driver is fallable.
The underlying takeaway is - donât use NTFS filesystems in Linux - unless you absolutely must; and, only if youâre prepared to maintain it properly - from observation, this rarely happens until a user becomes inconvenienced.
Neither NTFS3 or NTFS-3G should even come into the equation. A native Linux filesystem such as EXT4 should be the natural choice for any Linux system. 
Cheers.
I think you confused.
I was saying:
I did not mention âmountâ at all in my post.
The data corruption happened during file transfer, between NTFS to NTFS partition.
Itâs not a single incident, but happened whenever there is a file transfer.
Again, you confused.
The data on destination drive was corrupted, and irrecoverable, in either Windows or Linux.
And no, it happened on multiple HDDs that are 100% functional, and I can confirm this is not HW related.
It never happen again once I blacklisted NTFS3 and used back NTFS-3g.
Are you becoming personal here?
As both NTFS3 and NTFS-3G are included in the kernel, should we blame Linus Torvalds?
And also blame him for including BTRFS, ZS, etc. in kernel, cuz it should never come into the equation?
I dun mean to be personal - u can show support of your preferred FS, but when other users seek FS support, u pointed finger âblame yourselfâ at the user and said âur FS should never be included in the kernelââŚ
I dunno - I feel youâre getting personal.
1 Like
No. Well, maybe. I was attempting to give some background into reasons why the NTFS3 kernel module is often accused, whereas common misunderstanding is frequently a factor. Thus the reference to âmountâ.
I canât possibly know the cause and circumstances surrounding your apparent corruption. Again, see the comment above. However, that it never happened again using NTFS-3G is hardly conclusive. My personal opinion is that NTFS filesystems should never be used in Linux; that said, I do use them myself, sparingly (in multiboot scenarioâs with Windows).
Well, I wasnât, but it looks like youâre attempting to paint it in that frame.
NTFS-3G is a user space package. To the best of my knowledge, it is not and cannot be (in its current form) included in the kernel - NTFS3, however, is a kernel module (driver). Nonetheless, NTFS-3G was the default driver for NTFS for time, as I now understand it, although my previous understanding was that it was the free variant of a separate Paragon offering to the community. It can get confusing when tracing the respective histories.
Now, thatâs not only out of context, but also, just plain silly.
I think you are confused. NTFS is not my âpreferred FSâ.
Neither NTFS3 or NTFS-3G are filesystems - they are both drivers for the NTFS filesystem - there is a great difference.
Iâm uncertain just what youâre attempting to communicate here. âBlame yourselfâ was used in a casual and non-belligerent manner. Your accumulated inputs to this thread clearly show that you were not seeking support, but simply adding your own opinion to the mix; and, thatâs fine. However, please do not represent that you were asking for support (when you were not) while spouting this nonsensical rubbish in the process.
Cheers.
While I donât much like using NTFS in a multiboot scenario, I have to agree with you. I have never encountered any issues with NTFS (using the NTFS3 driver) that were not the direct result of something else; for example, a temporary hardware failure, a hard reset, failure to disable Fast Startup in Windows, ignorance or just plain stupidity. I can setup a multiboot system built-to-order, but I can never guarantee what a user might do with it afterwards. 
I have also never known the NTFS3 driver to cause the supposed corruption that some speak of, nor have I seen any confirmed bugs. 
Most of my externals are either NTFS or EXFAT formatted (as purchased). I admit, Iâm concerned about that, to some extent; but more due to the quality of the respective controllers than the filesystem. Some of them can fail if you fart.
Cheers.
1 Like
Again, youâre confused.
I never allege that âNTFS is your preferred FSâ, but I do get the impression that EXT4 is your preferred FS.
I also wish to emphasize that you have the freedom to express which FS is your preferred FS, and I respected it.
However, I do not appreciate your view which belittled other FS.
The feeling is mutual.
The OP stated he has a FS corruption issue with NTFS3, but your posts were about dirty bits, and EXT4 should be used, blah blah.
I was not looking for support in this post - this much is clear.
So I did not understand where you get the impression that I was asking for support.
For me, I had faced similar encounter with the corruption issue the OP faced, and I wanted to share that the issue is NTFS3 related - so blacklist NTFS3 and revert back to NTFS-3G would be the solution for now.
Now, I do not intend to extend further âdiscussionâ with u on this post, which IMHO, would be irrelevant to OPâs needs, and, especially in your view, everyone else is talking rubbish.
You can definitely argue that youâre using that phrase âin a casual and non-belligerent mannerâ, however, I dun think everyone else would feel the same.
1 Like
As you say,
I know your type.
Have a nice life. Cheers.
Closed due to pointless dogmatism.