File Systems FAQ

From ReactOS Wiki
Jump to: navigation, search

ReactOS uses file system drivers just as Microsoft® Windows® NT does. For that reason, it implements the Installable File System (IFS) interface. Therefore ReactOS will be able to load and use IFS-drivers. At the time of writing, ReactOS was still unable to load Microsoft® Windows® NT-native IFS-drivers. But sometime in the future, ReactOS will be able to load even native NTFS-drivers.

Also check out this FAQ on OSR Online

FAQ

Does ReactOS support Ext2/Ext3/NTFS?
  • It did support Ext2 for a while, though that was removed to make room for another FS.
  • NTFS has read-only support and experimental, minimal write support (disabled by default since it is incomplete).
  • ReactOS mainly supports FAT file systems including FATx(Xbox variation of FAT) and BtrFS.
  • Once the cache manager rewrite is finished there will be a push to make ext2 support available.
Why isn't NTFS write support supported in ReactOS?

NTFS is very hard to implement. The only implementation that is near-complete is NTFS-3g (FUSE), which is not kernel-level.

Reasons are:

  • NTFS is a very complex file system.
  • It's not documented. For this reason, it is more difficult to create an implementation. It doesn't assure full compatibility with Windows® in unusual circumstances nor with future versions of Windows®.

You can find exhaustive discussions in ReactOS Forum for further details. Here are some to start:

Someday, when ReactOS can handle it (kernel) you could use the NTFS driver from Windows®, but ReactOS will never recommend this for various legal reasons. Eventually, someone WILL finish writing a true NTFS driver for ReactOS, whether it's an adaptation of a Linux one (unlikely) or written from scratch using black-box hacking and available reference materials. Please wait patiently.

Can we implement the FreeDOS version of the FAT32 file system?

ReactOS has had support for FAT32 for ages. There's no need to implement another one.

Does ReactOS support VFAT and long names?

ReactOS natively supports long and Unicode filenames. It depends on how the file system driver decides to deal with it. The FAT-driver delivered with ReactOS supports VFAT (=long names on FAT).

Why not implement Ext2/3 instead of focusing on NTFS?

Because NTFS is a major feature which must eventually be supported. Ext2/3, is, of course, a topic for us, however, there are already projects whose goal is to implement Ext2/3 for NT. We will utilize these drivers when they are good enough and ROS is able to use them.

Where can I find the Ext2/3-IFS for NT?

You can find it here:

Can I help with programming installable file system drivers?

Yes, there's lots of work to do around IFS-drivers. It is, however, very hard to program. It could be said that programming drivers is hard but programming file system drivers is the king's discipline. If you are a real kernel hacker, come to our mailing list and announce yourself.

Can we use Ext2/3 instead of poking around in NTFS?

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 both read and write. So there's still lots of work to do and so the only option is the FAT-IFS.

Why not utilize the Linux-NTFS project's sources?

These sources are useful, but as with all NTFS implementations (except the one from Microsoft), it lacks writing support. And there are still big areas of NTFS which are undocumented/unknown. We are working together with them – or for now – just using their code. At the moment, there is no priority for NTFS, so active contribution in this area is still dormant.

How critical is NTFS support for ReactOS to be successful?

The ReactOS Project will eventually see NTFS support as a priority, but for now, there is no critical reason to have it. NTFS is primarily a hard disk file system, so the only reason one would absolutely need it would be is if you wanted to access an NTFS-formatted physical partition on an installed hard disk when using ReactOS. 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.

The JFS sources (also for OS/2) are free to download. Why not make JFS the standard file system in ReactOS?

Yes, at least an IFS is already planned. Since JFS is still a state-of-the-art file system with journalling, big file and partition sizes, ACLs and extended attributes and hard links, it would well suit ReactOS. We are working on it but you are welcome to help.

How do you deal with case sensitivity (i.e. ext2)?

Case sensitivity is not a problem of the file system itself. It's an aspect of the corresponding driver. 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 driver must, therefore, be able to handle both, case (in)sensitivity.

Can a 64-bit file system run on a 32-bit machine?

Yes. The 64-bit part is just the addressing on the disk. It has nothing to do with the executable which contains the driver. That executable has as many bits as the whole operating system has.

What file systems does ReactOS support, now?

FAT(12/16/32) plus VFAT, ISO-9660 – CD-ROM, NPFS – named pipe file system (internal FS), MSFS – mailslot file system (internal FS), BtrFS, and possibly Reiser

What file systems will ReactOS support?

Our goal is to support as many file systems as possible. IFS-drivers can be developed for at least the disk file systems that Linux provides. It is, however, very hard to program a compliant/working file system driver. So it will take some time. There will be at least: FAT(12/16/32) plus VFAT, ISO-9660 – CD-ROM, a higher FS like ext3, NTFS or JFS, NPFS – named pipe file system (internal FS), MSFS – mailslot file system (internal FS).

Why not discard these odd drive letters?

This is an old idea. Microsoft has probably had this idea, but they have not implemented it yet. In the ReactOS team, there are also thoughts about this issue. But up to now, there has not been a sufficient conclusion on this topic. There are ideas such as having a memory based mount file system or uncovering the object manager's namespace to win32 apps or drive words, but each approach has disadvantages. Note: The ReactOS/Microsoft® Windows® NT Kernel doesn't actually work with drive letters. These are a relic of DOS (or should I say CP/M) in Win32.

What is a Redirector?

This is a special form of IFS driver. It doesn't implement an 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).

What is a file system recognizer?

A real file system driver is a heavyweight. Loading one just for it to see that there is no partition it can mount is a waste of time. For this reason, Dave Cutler invented the so-called recognizer driver. This is more or less an integral part of the driver architecture. This driver gets loaded and searches partitions for file systems its companion IFS is capable of reading. If it finds such a partition it loads its companion IFS to mount it.

Why won't ROS work on NTFS/ZFS/REISER4/whatever right now?

This issue keeps cropping up, with people suggesting/pushing for the inclusion of some file system or another. Please stop worrying about this. NTFS is on the roadmap, ext2 is being worked on (I think) and by extension, that'll eventually evolve to ext4. It will get there when it gets there. So people who are pushing for those two, stop worrying.

For those who are pushing other file systems, you need to realize something. The kernel is extremely incomplete. Even if we had a fully functional FS driver, there's no guarantee it would work. We have a FAT32 driver because we need something to use for writing things, and FAT32 is probably one of the simpler file systems. The ext2 driver is because one of the devs or someone was interested enough to create it.

The devs are currently focusing on getting things to work and stabilizing them at the OS level. If you want a driver for this or that FS, you'll have to write it yourself. The developers just do not have the resources to fulfill FS requests. Therefore, suggesting an FS won't really do anything.

People keep pointing to NTFS-3G and keep bothering us about it. First of all, this is a Linux driver. Second of all, this is a user-space driver. Third of all, it's still relatively incomplete. It has the basics, but none of the tricky stuff. Those three factors mean it's useless to us right now. At best, it would serve as a reference for when we do work on our own NTFS driver. At worst, it's useless to us.

In conclusion, let's lay out all the facts

  • ReactOS currently only supports FAT file systems including FATx(Xbox variation of FAT), BtrFS, and possibly Reiser. NTFS read-only support exists.
  • Once the cache manager rewrite is finished there will be a push to make ext2 support available.
  • Someday, when ReactOS can handle it (kernel) we could use the NTFS driver from Windows®, but ReactOS will never recommend this for various legal reasons. Someone WILL eventually write a true NTFS driver for ReactOS, whether it's an adaptation of a Linux one (unlikely) or written from scratch using reference materials.
  • Someday, other less common file systems will be supported... For now, be happy we can handle FAT partitions so well. We don't have the manpower to write 20 FS drivers... if you KNOW how to do this feel free to contact us. WE HAVE BIGGER ISSUES (stability, GUI, hardware/software compatibility, etc...).
  • Yes we know there are other efforts out there to make Windows® access other file systems; there is no use in discussing them. Someday ReactOS will support it (just like every other Windows® app).
  • FAT, NTFS, and EXT2/EXT3 represent the major file systems out there.

See Also

Retrieved from "https://reactos.org/wiki/index.php?title=File_Systems_FAQ&oldid=50904"