It’s not a separate package. It’s the in-kernel driver, and in recent kernels, it is the default.
ntfs-3g is a separate package, and whether it’s installed or not, if the default is to use ntfs3, then ntfs3 needs to be blacklisted and ntfs-3g used instead. If ntfs-3g is already installed, then reinstalling it won’t cause any problems.
There’s an echo in here… 
Not really. @bendipa1 asked the question how I knew that it’s not already installed. My response meant to convey that I don’t know that, but that if it is indeed already installed, then reinstalling it won’t cause any harm, and therefore, the command I gave to the OP would still work. 
Ah, so, something like this …
Got it! 
OK. Thnx for that… Now I know, although on other Linux dists I’ve used ntfs-3g seems to be a package that always comes with them.
Hi. This also solved my problem. Definitively this is an error of the latest update of manjaro, not something related to disks.
Despite there being endless duplicate threads on this same subject, and numerous posts in each thread outlining the situation to varying degrees of verbosity … somehow … the basics are continually skipped over.
There is a new module in new kernels ntfs3 … in the past ntfs-3g was used.
ntfs-3g would more or less use --force by default … meaning it would mount ntfs partitions even if they were marked dirty.
You can go back to using ntfs-3g by making sure it is installed and blacklisting the new module.
But in most cases this is likely just willfully ignoring the real problem (and possibly causing continual harm to your partition and its data).
Its quite possible there are situations where the new ntfs3 is failing for no good reason.
I dont use the proprietary filesystem enough to have much of an opinion on the new module.
But complaining that ‘something broke because of an error from the update’ is missing the mark on numerous counts - and quite possibly facilitates continued bad practice.
( use the corpo OS, or a derivative like Hirens, and run chkdsk on the problematic partitions, then treat them correctly moving forward, like properly unmounting, and disabling ‘fast startup’ in windoze and so on )
No, this is wrong: I had two disks with NTFS format, one old and another completely new. I checked both with chkdsk with no error at all in any of them. The problem IS NOT in the partition or disks, its a problem in manjaro new driver or update. Stop lying and complaining about drives or disks, the source of the problem is completely clear.
That may be true in some edge cases. That doesnt make me a liar.
Also … besides checking their state while in windoze - did you ensure you unmounted them properly? Was windoze shutdown all the way? Are you sure?
PS.
Its also not a ‘Manjaro thing’ … its a Linux thing.
I think it’s more of a Windows thing. Linux, and Linux filesystems work properly, and is not as easily harmed…
The only Linux thing I can think of is stability. Reliability.
The comments from @cscs – apart from perhaps being more verbose than needed – were valid. Please, do not insist that someone is wrong simply because you have not experienced something yourself.
That is often called 2-dimensional thinking.
Also, please do not call someone on this forum a liar, simply because you fail to understand what is written before your eyes.
There are terms to describe that, as well, but, I digress.
Let’s keep it civil, and polite, OK?
You are getting it wrong.
If the disk(s) are in a unclean state - then Windows is not shut down completely - thus leaving the file systems in a so-called ‘dirty’ state.
Depending in the driver in use - kernel driver ntfs3 vs user-land ntfs-3g the system may refuse to load the file system - caused by the ‘dirty’ state.
This is not a flaw in the kernel - it is a security measure - much in the same sentiment which causes btrfs to refuse to write to a filesystem with errors - a measure designed to not alter data beyond repair.
So it is not a fault caused by an update - it is a fault caused by an improper Windows shutdown - a shutdown which is not improper from a Windows perspective but a fault caused by you - the user - trying to access a foreign file system which cannot be opened for rw.
The point is that the introduction of the ntfs3 module was in to the Linux kernel.
So regardless of the other foundations of the statements here the idea of laying blame on Manjaro was doubly (if not triply, etc) misguided.
This won’t hinder Windoze to mark the FS dirty when hibernating (instead of shutting down)!
Yes, but it would mount them read-only. That’s an important nuance.
Also, the reason why ntfs3 is the default nowadays is that it’s GPL’d, and therefore it’s in the kernel. ntfs-3g is licensed differently, and the GPL forbids inclusion in the kernel because the license for ntfs-3g is not compatible with the GPL — just as in the case of zfs.
This broke my installation, had to timeshift restore.
Also same issue here. Checked the drive on a Windows machine, it was removed properly and not in a dirty state.
You might find this information useful for future reference:
Otherwise, I dare say the current thread has passed its use-by-date; and is deserving of some closure… @Aragorn
note: there is also exfat which handles really large memory usb/sdcards etc. typically 128Gb or bigger.
requires exfatprogs to be installed.
I would agree, but seeing as there appears to be a renewed interest in this thread, let’s see where it goes… 
Fair comment; and perhaps the closure is premature. Either that or I’ve had my fill of NTFS for a time, due to writing the aforementioned primer.