Messages in this thread | | | Date | Wed, 02 Sep 1998 14:22:01 -0700 | From | Hans Reiser <> | Subject | Re: Implementing Meta File information in Linux (and a note at the end on current reiserfs status) |
| |
I think we might be less far apart than we are aware of.
Hans
Theodore Y. Ts'o wrote:
> Hans, > > I'm not sure why you reacted so violently to my posting. I also have no > idea what you are talking about when you say that my proposals > necessarily means "Structured Storage", or exactly what you mean by > that, and why it is such a horrible thing. If you could define > "Structured Storage" and then give a quick run down about why it's so > horrible, that would be helpful. I certainly wasn't suggesting that > glibc would be taking on the role of namei(), so I think there is some > massive confusion going on here.
Structured Storage is this Microsoft thing used for aggregating objects into files. Things like word processors and spreadsheets use it for storing complex documents/spreadsheets/other_objects with lots of subcomponents in a single file. It is part of OLE.
There is nothing that Structured Storage does that directories and archival programs can't do better.
To access a sub-object within a file in Structured Storage you must use a different API from that used to access a file. This increases code complexity and decreases symmetry and expressive power.
I want to encourage us not to start down the slippery slope that lead to Structured Storage. The reason that I react so violently is that what seems to you like a minor reasonable proposal for seems to me like a course that might evolve if not objected to into storing objects sometimes as files and sometimes as objects within files, using a separate API that will inevitably grow into a monster like Structured Storage.
> Point the second, given that the utility programs --- cp, tar, etc. --- > don't know about this non-standard resource forks, they won't be able to > properly copy these files, causing all sorts of confusion. Yes, we > could modify them to know how to copy the metafile information, but in > that case what's the advantage of storing the a resource fork? You > might as well store it in a separate file, since you'll have to modify > the user-mode code anyway.
cp and tar can handle directories. Changing the utility programs to handle directories that if read resolve to directory/default is a lot less work than implementing the functional equivalent of Structured Storage. Actually, I think they will simply never notice that the directory can be read, and that will be acceptable.
> > > Point the third, if critical application-specific information is stored > in the resource forks, standard Internet protocols such as ftp and http > won't be able to deal with files with multiple data streams.
Don't implement as multiple data streams, implement as directories.
> > > As I mentioned before, NTFS has support for multiple data streams. > According to a Microsoft developer, they aren't planning on using this > feature for much, precisely because of these concerns, which are really > external to the whole filesystem design question. > > - Ted
I suspect we are less far apart than we realize. Do you really object to the use of a filename.forks directory? I think not, am I right? All we are really arguing about is whether filename should be resolved to filename/default when filename is read and is a directory, yes? And NFS can get around it by nothing more dramatic than accessing it as filename/default rather than filename, yes? I imagine that an API that if using NFS adds /default to the end of filename would be a rather simple one. Actually, I bet that the API can just always add /default to the end of filename, and it will be better. So okay, I can concede that if the API resolves filename to filename/default, when filename is a directory, this is fine as an API. Do you think it solves the problem? (I do.)
Hans
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
| |