[ros-dev] Security policy for FAT partition driver?

Mike Nordell tamlin at algonet.se
Thu May 12 10:57:18 CEST 2005


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



More information about the Ros-dev mailing list