I have intentionally stayed out of this discussion, since it seems it's much about personal preferences and less about what I believe initially likely matters more for ROS - a way for the users coming to ROS to continue to use their existing data.
I believe that for this argument to be constructive, first it has to be decided what users are most important, or even likely, to be able to see the priority of FS implementations: - New users that have no previous data that matters to them. - Users migrating from Windows, currently using NTFS. - Users migrating from unix-like operating systems.
Considering ROS will be a way for people to get out of the Microsoft treadmill while continue to use a familiar environment (and for developers, API) it would seem like a logical conclusion that the majority already have filesystems usable from Windows. Unless those users are coming from a Win9x environment, chances are it is NTFS.
I personally know of people willing to get away from Microsoft but having terabytes of data that would be unaccessible from ROS should an NTFS driver not be implemented, making those potential users not even bother to sneeze. Even if given a path to migrate that data to a filesystem supported by ROS; would _you_ want to migrate one or more terabyte(s) of data from something proven reliable (so far) to something almost unknown? Would you do it if you suspected it was a one-way trip? I sure know I wouldn't, and neither would they.
Robert Köpferl wrote:
So coming back to ext?. There exists a rather good implementation for WinNT:
I would say "rather good" is nowhere near the rock solid stability required for a filesystem. The filesystem is _the_ most important piece for a system (and its users), since it is what is supposed to hold and safeguard its data. Everything, and I do mean everything else can be replaced, but some data is unique and cant be replaced (start rant about backup...). Applying the often disliked Microsoft-mantra of "good enough" in this area seems more like asking users to become part of the Shroedinger experiment - only catch is that the users data would be the cat.
Multiple File streams. NTFS is (looking at the mentioned table) the only FS capable of that feature.
Actually, that's also not entirely true. BFS, the filesystem for BeOS also had/has it (*), though much better integrated into the OS and tools (of course?), and... didn't Apple HFS use a different stream for the resource fork?
(*) In form of named properties. To be even more correct, BFS named attributes are at the FS level more like NTFS' attributes, even that they can also store data much like a named data stream in NTFS.
Taking a little detour: While multiple (named) streams display the complete incomptibility with most other filesystems in the world, at least if you want to move a file using Z-Modem or something similarly primitive, I have yet to decide which way is the best for general use - using but a single data stream for simplicity and compatibility with systems back from BC, or go for multiple streams for expressive power.
Having used NTFS, where this is very poorly integrated (when at all) into the OS, API and tools, and BFS where the very good OS integration made it feel just "natural", I suspect multiple streams indeed is the better way, but it can't be used to a fraction of its potential with the primitive API's or API semantics used since BC (this essentially includes the Win32 API and tools).
While the rest of the computing industry have moved quite a bit in the last 25+ years, FS semantics and API's have esentially been standing still. Having used "something better" (my subjective opinion based on BFS+BeOS), I'd say this standstill is not because the current paradigm is good enough. Compared to just that "something better" I'd say current paradigm sucks.
Even more OT opinions: While it would be really nice to lift this up to at least the level of the BeOS+BFS functionality, this is not the place. At least not yet. Once ROS is more mature and complete I wouldn't mind see this added for a new filesystem, making ROS take a leap. But that's currently so far into the future that raising the question now is really pointless. There are lots and lots of grunt-work more important before starting to add features and extending API's, filesystems and network protocols, making ROS apps taking advantage of these improvements incompatible with Win32/NT.
/Mike