Re:[ros-general] filesystems / links / file types

---------- Initial Header -----------
> From      : [e-mail]

To          : [e-mail]
Cc          : 
Date      : Fri, 27 Feb 2004 13:05:33 +0100
Subject : [ros-general] filesystems / links / file types
> hi,
>
> Which filesystems will reactOS support? 
> The current version just understands FAT, somewhere I read you plan NTFS.
>
> but, why?

Supporting is not a "why" question, but a "what" question.
> wouldn't it be much better to use ext2/ext3 or similar?

There are GPL'd drivers for ext2/3 on the net ("what").
> the links... 
> one serious drawback of windows is the lack of "real" links.

I used hard links since NT 4.0. And symlinks since NT 5.0 (2000). You just need a NTFS logical volume and a pair of utilities MS does not distributes...
> ever tried to use links as if they were the real files? 
> it simple does not work most of the times. this really is annoying.

These are probably *.lnk files, which are serialized references used internally by explorer.exe. Why should they work?

ea

[robert K.]

I've made a Q'n'D FS-FAQ (attaced)

I begg you to review for semantic errors. Where I spread the untruth.
And if you find spelling errors you're also welcome to mention them.

[Vizzini]

On Fri, 2004-02-27 at 12:22, robert K. wrote:

[only editing for technical content]
> as WinNT and WinXP also uses. At the time of writing there was still a
> problem known as the SEH-Problem which prevents ReactOS from using
> these drivers. But when the SEH-Problem is solved some time, ROS will
> be able to load even native NTFS-drivers.

Not really true; we need to do lots of work still.  It's on my plate, or
anyone else is welcome to it.
> Q: Can I help programming installable file system drivers?
> A: Yes, there's lots of work to do around IFS-drivers. It's however
> very hard to program. I like to say that programming dirvers is hard
> but programming file system dirvers is the king's discipline. If you
> are a real kernel hacker, come to our maling list and anounce
> yourself.

I am also happy to point you in the right direction.  There is much to
be done, as I said.
> Q: Can we use ext2/3 instead of poking around in NTFS
> A: Yes, it's up to you, which file system you want to use. For now
> however neither the ext2/3-IFS nor the our NTFS-IFS is ready to use
> for read and write. So there's still lots of work to do (especialy the
> SEH-Problem) and so the only option is the FAT-IFS.

Just to be precise: what SEH problem are you referring to?
> Q: Why do you not make use of the Linux-NTFS project's sources?
> A: These sources are rather ok, but as all NFTS implementations (but
> the one from MS) it lacks writing support. And there are still big
> areas wich are undocumented. We are working together with them or just
> using their code. In the moment ther's however not that priority for
> NTFS.

I don't think this is true any more; last I heard, there was an NTFS
implementation for Linux that could write.  Regardless, the big problems
here will revolve around 100% bug-compatibility with the MS code.

-Vizzini

[robert K.]

Vizzini wrote:
> On Fri, 2004-02-27 at 12:22, robert K. wrote:
>
> [only editing for technical content]
> > as WinNT and WinXP also uses. At the time of writing there was still a
> > problem known as the SEH-Problem which prevents ReactOS from using
> > these drivers. But when the SEH-Problem is solved some time, ROS will
> > be able to load even native NTFS-drivers.
>
> Not really true; we need to do lots of work still.  It's on my plate, or
> anyone else is welcome to it.
> > Q: Can I help programming installable file system drivers?
> > A: Yes, there's lots of work to do around IFS-drivers. It's however
> > very hard to program. I like to say that programming dirvers is hard
> > but programming file system dirvers is the king's discipline. If you
> > are a real kernel hacker, come to our maling list and anounce
> > yourself.
>
> I am also happy to point you in the right direction.  There is much to
> be done, as I said.

???
> Just to be precise: what SEH problem are you referring to?

Borland or we have no SEH compliant compiler. I include that.
> I don't think this is true any more; last I heard, there was an NTFS
> implementation for Linux that could write.  Regardless, the big problems
> here will revolve around 100% bug-compatibility with the MS code.

Yes, it can write. But only on the same clusters. no reallocation is 
possible nor deletion of files. Or using the MS-ifs through a wrapper.
> -Vizzini
>
> ros-general mailing list
> [e-mail]
> http://reactos.com/mailman/listinfo/ros-general

[Vizzini]

On Fri, 2004-02-27 at 13:01, robert K. wrote:
> Vizzini wrote:
> > > Q: Can I help programming installable file system drivers?
> > > A: Yes, there's lots of work to do around IFS-drivers. It's however
> > > very hard to program. I like to say that programming dirvers is hard
> > > but programming file system dirvers is the king's discipline. If you
> > > are a real kernel hacker, come to our maling list and anounce
> > > yourself.
> >
> > I am also happy to point you in the right direction.  There is much to
> > be done, as I said.
>
> ???

I still have to backport the Captive stuff into our tree.  It's not
directly portable, so it's going to be a (very interesting) pile of
work.  I'd put this up there near PnP support in level of effort.
> > Just to be precise: what SEH problem are you referring to?
>
> Borland or we have no SEH compliant compiler. I include that.

Support for drivers compiled with Microsoft compilers is not a problem,
other than some minor OS bugs that will get worked out during the
Captive merge.  We're not really blocked on SEH at all, at the moment. 
We may never be, either; GPL doesn't require that you do NOT give out
binaries, only that you accompany them with source.  If the thing
requires MSVC to build SEH-enabled binaries, that's not the end of the
world.  There's also nothing wrong with manually building the SEH frames
during coding - it's just a lot more tedious than letting the compiler
do it.

Also, FWIW: Borland owns the most often-cited SEH patent; I'd say they
probably have an SEH-compatible compiler.
> > I don't think this is true any more; last I heard, there was an NTFS
> > implementation for Linux that could write.  Regardless, the big problems
> > here will revolve around 100% bug-compatibility with the MS code.
>
> Yes, it can write. But only on the same clusters. no reallocation is 
> possible nor deletion of files. Or using the MS-ifs through a wrapper.

I see.

-Vizzini