lkml.org 
[lkml]   [1998]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

\
 
 \ /
  Last update: 2005-03-22 13:44    [W:0.199 / U:0.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site