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/