[ros-general] Microsoft wants royalties for use of FAT

Frank D. Engel, Jr. fde101 at yahoo.com
Mon Dec 8 10:51:50 UTC 2003


> >Named streams could either be dropped,
> 
> unlikely. Some programs are already using them
> 
> >or supported by storing in multiple files.
> 
> streams aren't files. Opening different streams opens the same file -
> i.e. 
> the same node. What are you going to do, maintain a second table of
> nodes 
> in a hidden file?

That would be very similar to the way Apple, under MacOS < X, stored
forked files (similar to multiple streams; but only two of them under
MacOS - data and resource forks) on FAT volumes, to support
cross-platform capabilities.  So yes, that is not completely
unreasonable. (they used a [hidden?] folder on the FAT disk to contain
the resource 'fork', which was given the same name as the main file, in
turn containing the 'data fork'.)

> >object IDs could be stored in attributes.
> 
> nope, they can't. They aren't attributes, they are identifiers: you
> can 
> open files by their object id. What now, another hidden file to index
> 
> object ids?

Not neccessary under BFS: indexes are integrated into the filesystem. 
Just turn it on for that attribute.  Searches are lightning fast with
BFS.
 
> >SIDs could be stored in attributes,
> 
> and this will waste any existing mechanism for access control and
> file 
> ownership. What I'm saying is that you can use Ext3 as the ReactOS's 
> official filesystem, just don't expect you'll be able to call the
> result 
> "Ext3" anymore, or actually share partitions with Linux without a
> special 
> driver. You can overload the meaning of "extended attributes" so many
> times 
> before you have created a new filesystem

Yes, and I don't wish to discount that.  I was merely offering a
suggestion on one way to avoid reinventing the wheel, if desired.

> >and the attributes could be indexed for efficiency -- this is all 
> >supported quite nicely by BFS.
> 
> Does BFS exist? I mean, an implementation we can use? 

The OpenBeOS project is creating one, designed for their OS of course,
which with some work, might be adaptable for use with another project;
they indicate it as being in late beta (just short of stable; IIRC this
is due primarily to thusfar insufficient testing to suit them), and
according to some of their testers, it is actually faster than the
original BeOS implementation, which was already lightning fast.

So this is a definite maybe; it depends on how easily the code could be
modified for use with ReactOS.


=====
=======
Frank D. Engel, Jr.

Modify the equilibrium of the vertically-oriented particle decelerator to result in the reestablishment of its resistance to counterproductive atmospheric penetration.

__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/



More information about the Ros-general mailing list