ReactOS uses file system drivers as WinNT does. For that reason it implements the IFS-interface which stands for Installable File System. Therefore it is or will be able to load and use IFS-drivers. The same as WinNT and WinXP also uses. At the time of writing ReactOS was still unable to load WinNT-native IFS-drivers. But some time, ROS will be able to load even native NTFS-drivers.
A: Reactos supports Fat32 for ages. There's no need to implement another one.
A: What are short names? OK. ROS natively supports long and unicode filenames. So it's up to the file system driver how it deals with it. The FAT-driver delivered with ReactOS supports VFAT (=long names on FAT).
A: Because NTFS is a major feature which must be supported at some time. Ext2/3 is of course a topic for us, however there exist already projects whose goal it is to implement Ext2/3 for NT. We will utilize these drivers when they get good enough.
You can find it here:
http://uranus.it.swin.edu.au/~jn/linux/ext2ifs.htm,
http://sys.xiloo.com/projects/projects.htm#ext2fsd and http://ashedel.chat.ru/ext2fsnt/
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 mailing list and announce yourself.
A: Yes, it's up to you, which file system you want to use. For now however neither the Ext2/3-IFS nor our NTFS-IFS is ready to use for read and write. So there's still lots of work to do and so the only option is the FAT-IFS.
A: These sources are rather ok, but as all NTFS implementations (except the one from MS) it lacks writing support. And there are still big areas of NTFS which are undocumented/unknown. We are working together with them or just using their code. At the moment, there is no priority for NTFS So it's still sleeping.
A: Good Idea. However there's no ReiserFS driver for NT/ROS available. You are welcome to program one. I think in the recent time there appeared a reiser-IFS in the net.
A: The ReactOS Project will eventually want NTFS support, but for
now, there is no critical reason to have it. NTFS is primarily a hard
disk filesystem, so the only reason one would absolutely need it would
absolutely need it. On reason would be if you wanted to access an
NTFS-formatted physical partition on an already formatted hard disk
installed in a ReactOS computer.
Other file systems will be able to provide the advanced features of
NTFS (journalling, ACLs, compression, hard links, etc.) if strict NTFS
compatibility is not a requirement. All software comes on CD or DVD
media (ISO-9660 or UDFS), or possibly on floppies (FAT). External media
(compact flash, memory sticks, etc.) tend to be formatted FAT.
A: Yes, at least an IFS is already planned. Since JFS is still a state of the art file system with journalling, big file+partition sizes ACLs and extended attributes and hard links, it would well suite ROS. We are working on it but you are welcome to help.
A: Case sensitivity is not a problem of the file system itself. It's an aspect of the corresponding dirver. The object manager which provides the whole namespace supports case sensitivity natively. So IFS-drivers get a special case flag which they must handle accordingly. A ported file system diriver must therefore be able to handle both, case (in)sensitivity.
A: Yes. The 64-bit are just the addressing on the disk. It has nothing to do with the executable which contains the driver. That executable has as manny bits as the whole operating system has.
A: For now, the only file system supported is FAT(12/16/32) without VFAT.
A: Our goal is to support as many file systems as possible. There
can be developed IFS-drivers for at least these disk file systems which
are available with linux. It's however very hard to program a
compliant/working file system driver. So it will take some time.
At least there will be:
A: Old Idea. I'd say that also MS has had this idea, but they have
not implemented it yet. Why? In the ROS-team there are also thoughts
about this issue. But up to now there has not been a sufficient
conclusion about this topic. Maybe MS is also still thinking.
There are Ideas as having a memory based mount file system or
uncovering the object managers name space to win32-apps or drive words.
Everything brings disadvantages with it.
By the way: The ROS/NT-Kernel doesn't work with drive letters. These
are a relict of DOS (or should I say CP/M) in win32.
A: This is a special form of an IFS driver. It doesn't implement a on disk file system. Instead it relies on the kernel's network stack and provides most times a remote file system (i.e. SMB-Shares).
A: A real file system driver is a heavy wight. Loading it just for it to see that there is no partition it could mount is waste. For this reason Dave invented so called recognizer driver. They are more less integral part of the driver architecture. Such a little driver gets loaded and searches partitions for file systems it's companion IFS is capable of reading. If it finds such a partition it loads it's companion IFS to mount it.
SEH-Problem: Structured exception handling (SEH) is used in programming ReactOS as it is used in programming for OS/2 or WinNT, too. SEH is a game which is played between OS and Compiler (Keywords: __try, __except, __finally). ReactOS itself is SEH-aware and provides the infrastructure. However up to now, the used GNU-compiler is not capable of generating SEH aware code. So one can't compile a driver or program which uses SEH with the GNU-Compiler.
© 2/2004 Robert Köpferl <>