From the WinBeta subforum of reboot.pro:
I'm Pierre Schweitzer, one of the ReactOS developers. This is a free operating system that aims to re-implement Windows, but this time with an open source license.
ReactOS now supports reading files from NTFS volume. This was a long awaited feature people were asking for. And here it is.
You can see what I'm talking about on the three pictures [included in the fine article].
(Score: 0) by Anonymous Coward on Thursday November 06 2014, @05:25PM
But I guess the Linux NTFS driver is Open Source, right? And the algorithms to read and write NTFS should not be OS dependent. Of course you cannot simply take the Linux driver as is, but why can't they take just the algorithm part from there, change Linux calls for disk I/O to corresponding ReactOS calls, and only write the API layer of the driver anew? Or if they do that, what's so complicated about it that it takes so long?
(Score: 4, Insightful) by arashi no garou on Thursday November 06 2014, @05:44PM
I'm no expert, but it's my understanding that there are two factors at play here. One, NTFS support on any non-Microsoft OS is partial, not full. Even as good as GNU/Linux support via FUSE can be, it's still dangerous to rely on for important data. Two, ReactOS is attempting to provide a Windows-compatible OS that is fully open source. Therefore, any attempt at read/write access to NTFS volumes must be reverse-engineered, since Microsoft won't release the source to NTFS. Given that NTFS has been the standard file system in use by consumer Microsoft OS releases since 2002, the ReactOS team want to achieve full compatibility, so they are being extremely careful in approaching that goal.
In other words, you don't want to try to use ReactOS on NTFS and suddenly have your data disappear because they just "borrowed" GNU/Linux's NTFS support. So they are attempting to implement their own ntfs.sys instead.
(Score: 0) by Anonymous Coward on Thursday November 06 2014, @09:25PM
I'm no expert
Hmmm.
NTFS support on any non-Microsoft OS is partial, not full
Linux has had stable read and write support for NTFS since early 2007. [google.com]
What do you perceive as missing?
...besides, y'know, proper file permissions--which MICROS~1 has never had.
dangerous to rely on for important data
...same as when using NTFS under a MICROS~1 OS--because NTFS is MICROS~1's homebrew technology.
There are no surprises in your statement.
...and, if M$ would document their 4th-rate protocols fully, it would be duck soup to reimplement them.
...but that would break M$'s business model of obfuscation.
.
Regarding the AC above: [soylentnews.org]
ReactOS [...] relies on wine
ReactOS did do a major rewrite back in early 2010. [google.com]
At that time, there was a serious cross-pollination between the 2 projects.
-- gewg_
(Score: 2) by arashi no garou on Friday November 07 2014, @02:06PM
Linux has had stable read and write support for NTFS since early 2007.
What do you perceive as missing?
I've had issues with corrupted NTFS volumes after extensive read/write sessions under GNU/Linux (specifically Slackware with NTFS-3G and FUSE) for several years now. These days, I'll only write to an NTFS volume over a network share; I don't dare mount the volume natively in GNU/Linux. Maybe it's just Slackware; maybe it's just my hardware. But I've learned my lesson the hard way.
The rest of your reply is blatantly biased against Microsoft (MICROS~1? Really? Grow up!) but I stand by what I wrote about the ReactOS team wanting to reverse-engineer NTFS instead of relying on NTFS-3G/FUSE, as I got it directly from their website. You can claim otherwise if you want, but you'd be calling them liars, not me.
(Score: 2) by monster on Friday November 07 2014, @05:44PM
Some of the most egregious fuckups in the filesystem would land you in "Run chkdsk from Windows on this volume" (aka "I won't touch this shit even with a ten feet pole") territory.