How far is ext2 support in ReactOS?

[Aeneas]

Well... For certain NON-technical reasons you might consider to go for ext2. Thing is, while you are attempting full binary compatibility, it is not too bad to keep at arms length regarding some MS design choices. I very well understand why you like NTFS. But in some ways, being a bit different from Windows might just "not be a bad thing"...

Besides, who knows how long MS is going to stick with NTFS "as we know it". It may still bear the name NTFS and have not too much in common with the NTFS under Windows 2000 or XP... It might be just wasted efforts on your part. Steve Jobs was actually right when he said that he tries not to run where the ball is, but where the ball will be.

[elhoir]

Ext2 has access rights, FAT doesnt! dont miss this!

Its absolutely a MUST for a proper security implementation!

[Haos]

Journaling you mean?

[fred02]

Ext2 has access rights, FAT doesnt! dont miss this!

Also symbolic and hard links and extended attributes and a generally better data organisation and reliability.

[mrugiero]

I think the correct choice is to don't make a choice at all.
There exists ext2 drivers for windows, and IIRC they're open source. It's far more easy to integrate it than to develop the NTFS driver, which means it could be a good step to bring this support while trying to get NTFS into a working state. Another advantage in having an ext2 driver is the interoperability when you have a dual boot. With a Windows-Linux dual boot, you have no choice but to keep your NTFS partition as storage if you use ext4 for Linux (well, I'm actually not sure, the last time I checked it was a year ago, I think), since you can read NTFS from Linux but not the other way around.
There is also the public specs (I'm not actually sure if they are specs, but you have at least source code which I hope is correctly commented), which I'm not sure how complete are in the case of NTFS.

Main advantage, IMO, is as a faster way to drop FAT. But NTFS keeps being a must.

[BrentNewland]

I think the correct choice is to don't make a choice at all.
There exists ext2 drivers for windows, and IIRC they're open source. It's far more easy to integrate it than to develop the NTFS driver, which means it could be a good step to bring this support while trying to get NTFS into a working state. Another advantage in having an ext2 driver is the interoperability when you have a dual boot. With a Windows-Linux dual boot, you have no choice but to keep your NTFS partition as storage if you use ext4 for Linux (well, I'm actually not sure, the last time I checked it was a year ago, I think), since you can read NTFS from Linux but not the other way around.
There is also the public specs (I'm not actually sure if they are specs, but you have at least source code which I hope is correctly commented), which I'm not sure how complete are in the case of NTFS.

Main advantage, IMO, is as a faster way to drop FAT. But NTFS keeps being a must.

From what I understand the issue for those kinds of drivers is that they're user drivers and not kernel drivers (the kernel needs to access the file system from the very start, which probably means a lot of stuff a driver might normally have available isn't accessible). But, I am not a C programmer so I might be completely wrong.

[EmuandCo]

Windows drivers never are User mode.
Dokan is a FUSE wannabe, but uses a way different approach to access files and i not IFS compatible, nor bootup compatible.

[vicmarcal]

Windows drivers never are User mode.
Dokan is a FUSE wannabe, but uses a way different approach to access files and i not IFS compatible, nor bootup compatible.

Dokan+Fuse4Win+NTFS-3G
That is

[mrugiero]

Windows drivers never are User mode.
Dokan is a FUSE wannabe, but uses a way different approach to access files and i not IFS compatible, nor bootup compatible.

Really? There is a hot discussion in Phoronix about taking Linux drivers to userspace, and there is a crowd who stands most Windows drivers are user mode.
Anyway, I think you probably know a lot more about Windows than a few trolls in a Linux forum.

From what I understand the issue for those kinds of drivers is that they're user drivers and not kernel drivers (the kernel needs to access the file system from the very start, which probably means a lot of stuff a driver might normally have available isn't accessible). But, I am not a C programmer so I might be completely wrong.

Hmmm, I recall of one driver which were kernel mode IIRC. I don't know if it was open source, though.
The ones which are known to be user mode are the Linux et al NTFS drivers. I was talking about ext2 drivers for Windows.

EDIT: This was the most promising one, but it doesn't seem to be open source, just freeware.
Here is another kernel mode ext2 driver, but this is far older than the previous one.

EDIT: After all, this seems to be the best choice.

[aicommander]

OK as it stands now:

- Usetup (1st stage setup) can create a format an ext2 volume
- FreeLoader (unlike NTLDR) CAN boot ReactOS from ext2
- The current issue is that it seems our ext2 driver has bit-rotted but Art has a new one which he can import which supposedly works
- However, the ext2 driver depends on NewCC which we're still working the bugs out of (random hangs, crashes)

Once NewCC is enabled, we should support ext2 (installing, booting, mounting, formatting, etc) assuming the new ext2 driver is imported by then.

[BrentNewland]

I hope you don't mind but I added your post to the Wiki http://www.reactos.org/wiki/File_Systems


I'm not a C developer or involved with ReactOS in that page or I would update the section on the Version Status Page myself http://www.reactos.org/wiki/Version_Status

[Black_Fox]

OK as it stands now: (...)

That's some great news, thanks for the info!

[Rosh]

OK as it stands now:

- Usetup (1st stage setup) can create a format an ext2 volume
- FreeLoader (unlike NTLDR) CAN boot ReactOS from ext2
- The current issue is that it seems our ext2 driver has bit-rotted but Art has a new one which he can import which supposedly works
- However, the ext2 driver depends on NewCC which we're still working the bugs out of (random hangs, crashes)

Once NewCC is enabled, we should support ext2 (installing, booting, mounting, formatting, etc) assuming the new ext2 driver is imported by then.

So when Victor Perevertkin finish BtrFS filesystem integration in ReactOS, ext2 will be implemented?

[ROCKNROLLKID]

OK as it stands now:

- Usetup (1st stage setup) can create a format an ext2 volume
- FreeLoader (unlike NTLDR) CAN boot ReactOS from ext2
- The current issue is that it seems our ext2 driver has bit-rotted but Art has a new one which he can import which supposedly works
- However, the ext2 driver depends on NewCC which we're still working the bugs out of (random hangs, crashes)

Once NewCC is enabled, we should support ext2 (installing, booting, mounting, formatting, etc) assuming the new ext2 driver is imported by then.

So when Victor Perevertkin finish BtrFS filesystem integration in ReactOS, ext2 will be implemented?

You realize that post is from 2012 right. And to answer your question, his application is for btrfs booting and fixing some issues in CC so btrfs can boot. The bugs fixes in CC could also help with ext2 booting, but I doubt he will work on ext2, unless he decided to continue his work after GSOC.

In my opinion he should just work on the winbtrfs driver to fix bugs, improve performance, and oplocks still need to be implemented in btrfs. I don't see much of a reason why we would need ext2 when we have winbtrfs.

[EmuandCo]

Rosh.... start to learn the dos and don'ts in a forum and do that fast. This time I ONLY lock the thread necromancy...