Difference between revisions of "File Systems"

From ReactOS Wiki
Jump to: navigation, search
m (update - talk about ext3/4, too)
(Deleted the very dated FAQ, Status updates should be made through updates to this wiki page instead)
Line 94: Line 94:
*'''VFD''' - virtual floppy drive for floppy images was implemented [http://github.com/reactos/reactos/commit/fc921423f35f442d419246b1dbbaf1e3f651f978 23-dec-2017]. (<s>{{JIRA|14090}}</s>)
*'''VFD''' - virtual floppy drive for floppy images was implemented [http://github.com/reactos/reactos/commit/fc921423f35f442d419246b1dbbaf1e3f651f978 23-dec-2017]. (<s>{{JIRA|14090}}</s>)
== FAQ ==
ReactOS uses file system drivers just as Microsoft® Windows® NT does. For that reason it implements the IFS-interface which stands for Installable File System. 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 some time in the future, ReactOS will be able to load even native NTFS-drivers.
''Also check out this FAQ on [http://www.osronline.com/article.cfm?article=17 OSR Online]''
;Does ReactOS support Ext2/Ext3/NTFS?:
* ReactOS currently only supports FAT file systems including FATx(Xbox variation of FAT).
* Once cache manager rewrite is finished there will be a push to make ext2 support available.
* Some day, when ReactOS can handle it (kernel) we could use the NTFS driver from Windows®, but ReactOS will never recommend this for various legal reasons. Some time after that someone WILL write a true NTFS driver for ReactOS, whether it's an adaptation of a Linux one (unlikely) or written from scratch using stuff out there as references.
;Why isn't NTFS 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:
* [http://www.reactos.org/forum/viewtopic.php?f=9&t=8180#p71875 Re: NTFS question]
* [http://www.reactos.org/forum/viewtopic.php?f=14&t=3537&start=0 Why ROS will not work on NTFS/ZFS/Reiser4/whatever right now]
* [http://www.reactos.org/forum/viewtopic.php?f=2&t=2516&p=50094#p50094 Re: NTFS-3G: Read-Write Open Source Linux NTFS FUSE Driver]
* [http://www.reactos.org/forum/viewtopic.php?f=2&t=8441&p=73851#p73851 Re: Will ReactOS be support to btrfs ?]
NTFS may be implemented in future development stages of ReactOS. 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 how the file system driver decides to deal with it. The FAT-driver delivered with ReactOS supports VFAT (=long names on FAT).
;Why don't you implement Ext2/3 instead of focusing on NTFS?:
Because NTFS is a major feature which must be supported at some time. 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.
;Where can I find the Ext2/3-IFS for NT?:
You can find it here: http://uranus.it.swin.edu.au/~jn/linux/ext2ifs.htm http://sys.xiloo.com/projects/projects.htm#ext2fsd http://ashedel.chat.ru/ext2fsnt/.
;Can I help 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 read and write. So there's still lots of work to do and so the only option is the FAT-IFS.
;Why do you not make use of 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.
;Does 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)
;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 these disk file systems which are available with Linux. 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).
;I have an idea: Why not throw away 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 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 an 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 it just for it to see that there is no partition it could mount is a waste of time. For this reason, Dave Cutler invented the so-called recognizer driver. They are 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.
Structured exception handling (SEH) is used in programming ReactOS as it is used in programming for OS/2 or Microsoft(R) Windows® NT. SEH is a game which is played between the OS and Compiler (Keywords: __try, __except, __finally). ReactOS itself is SEH-aware and provides the infrastructure. However, up till now, the GNU-compiler used is not capable of generating SEH aware code. So one can't compile a driver or program which uses SEH with the GNU-Compiler.
This issue keeps cropping up, with people suggesting/pushing for the inclusion of some file system or another. First and foremost, all I have to say is, 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 people who are pushing other file systems, you need to realize something here. 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 in order to write things on, 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.
Right now, the devs are 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. Suggesting a FS won't really do anything for that reason.
Edit: People keep pointing to NTFS-3G and keep pestering 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's got the basics done, but none of the tricky stuff. Those three factors mean right now it's useless to us. 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.
=== So to finally clear everything up let's lay out all the facts ===
* ReactOS currently only supports FAT file systems including FATx(Xbox variation of FAT).
* Once 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. Some time after that someone WILL write a true NTFS driver for ReactOS, whether it's an adaptation of a Linux one (unlikely) or written from scratch using stuff out there as references.
* 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; stop talking about them. Some day ReactOS will support it (just like every other Windows® app).
* FAT, NTFS and EXT2/EXT3 represent the major file systems out there.
== See Also ==
== See Also ==

Revision as of 18:59, 25 August 2019

This page contains information about file systems ReactOS intends to support.


Commit history (Source code can be found in: /reactos/drivers/filesystems/fastfat) Code Overview


FAT32 is a file system designed by Microsoft, introduced in August 1996 on Windows 95 OSR2. It is simple and easy to understand compared to other common file systems. The FAT file system is supported across a variety of other operating systems, including GNU/Linux, FreeBSD, BeOS, Mac OS X, and FreeDOS. This makes FAT32 an effective file system for sharing files between operating systems. It is also commonly used on flash media and external hard drives, which ReactOS intends to be able to read with pending USB mass storage support.


This is the file system which has been supported by ReactOS for the longest time by now, ReactOS can read, write and boot from it. The driver (fastfat.sys) has gone through several iterations, including an attempt to rewrite it with the FullFAT library. In the meantime Microsoft themselves open-sourced their fastfat.sys - attempts to integrate it into ReactOS have shown that our kernel isn't 100% ready yet.


See also FAT Security System Policy


Commit history (Source code can be found in: /reactos/drivers/filesystems/btrfs)


Btrfs is a Linux filesystem of the "next generation". It was designed to supersede the ext series of Linux filesystems. Principal features include:

  • Copy-on-Write (COW) - Instead of "deep copying", file copies start as light-weight references. On modification, the original data is left untouched. Foundation of the fast and "low-cost" Btrfs snapshots
  • B-tree design - in contrast to a table-based system like FAT
  • Maximum filesize of more than 16 Exabytes
  • Data checksumming - all data is checksummed on read and write - this can detect hardware errors previously undetected
  • Subvolumes - this feature allows to "partition" a Btrfs filesystem in separate filesystem hierarchies, which can be separately mounted - basis of the snapshot feature
  • Built-in RAID 0,1,5,6,10 support - a Btrfs filesystem can span multiple disks, the user can select trade-offs (RAID levels) between data redundancy/space economy and performance
  • Built-in compression support
  • Online defragmentation (defrag) and checksum check (scrub)
  • Btrfs snapshots - ideal for differential backup solutions


Since version 0.4.10 ReactOS can be installed on Btrfs. This includes support for creating Btrfs filesystems (in the installer at least), installing and running ReactOS (read-write) from Btrfs and a shell extension adding a "Btrfs" tab to the drive properties dialog. The driver used is a in-tree copy of Mark Harmstone's fully-featured WinBtrfs driver for Microsoft Windows. In 2016 Peter Hater and Pierre Schweitzer started the integration into ReactOS. As part of the Google Summer of Code 2018, Victor Perevertkin wrote the Btrfs support code for FreeLoader, allowing ReactOS to boot from Btrfs directly. The integration already allowed to send some bug fixes upstream to WinBtrfs proper.


Commit history (Source code can be found in: /reactos/drivers/filesystems/ntfs)


The New Technology File System (NTFS) is another file system designed by Microsoft. It was introduced with the NT line of operating systems, superseding FAT as the preferred file system. Details on the implementation's internals are not released, which makes it difficult to implement. Other operating systems, most notably Linux-based distributions, use NTFS-3G and the FUSE file system interface to support read and write access to NTFS partitions.


Targeted for ReactOS 0.5.0. Support for the NTFS file system is planned, but is not a priority. The first objective in this area is to be able to use the driver included in Windows XP, which would ensure ReactOS could support the file system.




Commit history (Source code can be found in: /reactos/drivers/filesystems/ext2)


The second extended filesystem (ext2) is a file system designed for the Linux kernel. It was introduced in January 1993 as a replacement for the extended filesystem (ext). ext2 was replaced by ext3, a similar file system with journaling, but is still popular for use on flash-based storage media. Because Microsoft provides no support for the extended file system, a file system driver had to be written by a third-party developer. The ext2 file system driver was originally developed by Manoj Paul Joseph before ReactOS developers began working on it and testing it on Windows. Filip Navara took interest and continued development on the driver.


The settings to format a HDD partition to ext2 are already included in the 1st stage setup, but are currently disabled. The ext2 file system driver itself is developed enough that it could be used. However, other components of the operating system need further development before ext2 can be used (in particular, the cache manager). Art Yerkes has been working to, among other things, provide a usable implementation of the cache manager in ReactOS. As of r44038, it is possible to boot ReactOS on an ext2 partition through building of the arty-newcc branch. Yerkes also added a _NEWCC_ switch (in r44092), which would allow merging to a trunk build and building with either the new or old cache manager implementation.


  • [EXT2LIB]
    • Fix formatting FAT or NTFS volumes into EXT2 by defining ZAP_BOOTBLOCK and fixing a bug in zap_sector()
  • [USETUP]
    • Enable ext2 as an option in setup

According to this topic (retrieved March 1st, 2012)

  • Usetup (1st stage setup) can create and 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 debugging (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.

28.09.2015 driver was rewrited with using Ext2fsd. 12.10.2015 in revision 897634c (r69509) he is was added to trunk.

Other file systems

  • According to Windows NT registry, almost all parts of network services, which running in kernel-mode are file system drivers, namely:
  • Btrfs - In 2016 Mark Harmstone published on github BtrFS-driver for Windows. Based on his code, developers have added support of this FS to ReactOS. (CORE-10892) During the GSOC 2018 Victor Perevertkin added support for ReactOS to install and boot on this FS.
  • ReiserFS was added in 2016. (CORE-11005)
  • NFS An open source NFS 4.1 file system driver has been released for Windows. Implementing by Pierre Schweitzer‏. [WIP]
  • ISO-images support was implemented in 03-Dec-2017
  • CDFS <=> ISO-9660
  • UDF was added in June 2017.
  • MUP
The multiple UNC provider (MUP) is a kernel-mode component responsible for channeling all remote file system accesses using a Universal Naming Convention :(UNC) name to a network redirector (the UNC provider) that is capable of handling the remote file system requests. Mup.sys
  • SMBFS is the file system used for Samba (network sharing for windows) - it's missing now
  • VFD - virtual floppy drive for floppy images was implemented 23-dec-2017. (CORE-14090)

See Also