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: 2) by WizardFusion on Thursday November 06 2014, @02:00PM
I thought we could read/write from NTFS anyway within Linux.? Read certainly.
What's so special about this then.?
(Score: 0) by Anonymous Coward on Thursday November 06 2014, @02:25PM
Things... things and stuff
(Score: 2) by Gaaark on Thursday November 06 2014, @02:42PM
Stuff... stuff and nonsense
--- Please remind me if I haven't been civil to you: I'm channeling MDC. ---Gaaark 2.0 ---
(Score: 2) by strattitarius on Thursday November 06 2014, @07:33PM
Slashdot Beta Sucks. Soylent Alpha Rules. News at 11.
(Score: 4, Informative) by MozeeToby on Thursday November 06 2014, @02:38PM
It's not Linux is the obvious answer. ReactOs implements the windows API in open source. In theory, you can run any windows application natively with no worries of comparability because the OS implements the exact same functions Windows does, including the APIs that aren't fully (or at all) documented by MS. That being said, I have no idea how well it works; not having used it myself.
(Score: 2) by WizardFusion on Thursday November 06 2014, @02:47PM
Ah, thanks.
+1 Informative
(Score: 1, Informative) by Anonymous Coward on Thursday November 06 2014, @04:48PM
ReactOS doesn't actually implement the windows API, it relies on wine for that. It just implements the windows kernel.
(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.
(Score: 3, Interesting) by Thexalon on Thursday November 06 2014, @02:47PM
Last I checked, you could reliably:
- read files
- overwrite files up to the size of the file you were overwriting
NTFS uses proprietary magic when allocating space to either create a new file or expand an existing file. There are at least experimental implementations of full NTFS read/write support, but Microsoft isn't exactly forthcoming when it comes to documenting it.
I would imagine that what ReactOS is doing is cross-fertilizing with Wine as well, since Wine has also largely implemented the Windows API, but running on top of a Linux platform. My guess is that ReactOS, if successful, would be a bigger threat to Windows than Linux/Wine, because a lot of businesses would be able to transition to it and get off of the Microsoft upgrade treadmill without really having to change anything they're doing. I have no idea how close they are to achieving that, though.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 2) by fnj on Thursday November 06 2014, @03:22PM
Sounds like FUD. NTFS-3G has had full read-write support for years. Files of ANY size can be created, modified, renamed, moved, or deleted. Hard links and symbolic links are supported.
(Score: 2) by Thexalon on Thursday November 06 2014, @04:15PM
Oh, right, I was thinking kernel support rather than a userspace tool, and the last time I built the kernel it still had those kinds of warnings about it.
I don't play close attention to these kinds of things, since I barely use Windows.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 2) by fnj on Thursday November 06 2014, @06:53PM
Understood. The kernel NTFS support is nothing more than a joke. But NTFS-3G using FUSE is not a kind of stunt of questionable value like ZFS-FUSE is. NTFS-3G is a fully performant first class file system.
If you want a read-write FS to share between linux-BSD-OSX-Windows (i.e., removable media) - even any two of those really, NTFS is pretty much the only choice except for the abomination of FAT.
(Score: 3, Insightful) by maxwell demon on Thursday November 06 2014, @07:05PM
FAT is a great file system for 360kB floppy disks. Which is what it was designed for. It wasn't designed for disks of several hundred gigabytes.
Calling it an abomination does not do justice to the file system.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 3, Interesting) by tangomargarine on Thursday November 06 2014, @03:22PM
Well, they've been working on it since 2004 (and even that was based on a previous abandoned project apparently) and they're still in alpha, so it'll be awhile.
Plus, I can only assume Microsoft will sue the living bejeezus out of them the instant it looks like they're actually going to publish a usable product. (What's that, APIs aren't patentable? Here, let me find a different judge who disagrees.)
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 0) by Anonymous Coward on Thursday November 06 2014, @04:20PM
Like say the Chinese Gov or similar...
(Score: 0) by Anonymous Coward on Thursday November 06 2014, @03:41PM
I'm sure the System D geniuses have already figured out how to integrate NTFS filesystem kernel modules at boot time, probably figuring out a way to couple it tightly with GRUB -- this way we could boot Linux off an NTFS partition as all the necessary I/O modules would be loaded at the earliest possible point in the boot cycle.
(Score: 0) by Anonymous Coward on Thursday November 06 2014, @04:25PM
Why are you in such a hurry to give the System D crowd, new ideas?
If you don't like the or what they are doing, then shut the fsck up and quit helping them think.
(Score: 2) by Freeman on Thursday November 06 2014, @04:55PM
ReactOS is an open-source implementation of the NT Architecture. I.E. Native Windows Support. They work/share with the Wine community, because they are working on some of the same kinds of things. Wine runs in the Linux OS. ReactOS is the OS.
Joshua 1:9 "Be strong and of a good courage; be not afraid, neither be thou dismayed: for the Lord thy God is with thee"