rothwell@flyingbuttmonkeys.com (Michael Rothwell) wrote on 11.08.00 in <3994B7A4.3612580D@flyingbuttmonkeys.com>:
> "Theodore Y. Ts'o" wrote:
> > "Named streams" and "extended attributes" are quite different. One
> > allows you to seek around, and read write parts of it, as a stream. The
> > other reuiqres that get or set the entire "extended attribute" all at
> > once; there is also usually some kind of size limitation with an
> > "extended attribute".
>
> But extended attributes can be implemented using
> named streams. This is, in fact, what Services
> for Macintosh does on NT/2000, and what MacOSX will
> be doing. BeOS provides extended attributes only.
In fact, traditional MacOS implements them as a database in a single
numbered stream (main data is stream 0, resource fork is stream 255, no
other streams ever exist).
> > In general, I tend to be very skeptical that using such things is a good
> > idea. There are far too many programs (cp, emacs, vi, shell scripts
> > that use pipes and redirection to rewrite files, etc.) that will cause
> > the extra data to get lost.
>
> Could you explain?
I've written a Mac copy program. It's a pain.
You need to copy the data fork, the resource fork, and the system file
attributes. (And that ignores external stuff in the Finder's database.)
You need about four times as many different system calls than on Unix to
accomplish this, and two copying loops instead of one.
If you don't do that ... well, the extra data gets lost.
> > There are far too many file formats (tar,
> > zip, etc.) that will cause the same problem.
>
> The important data is almost always the main fork.
Well, that's one theory.
But given that 68K *programs* usually had an *empty* data fork, maybe it's
not the right theory. (And font files. And Sound files. And ... you get
the picture?)
I've seen all manner of more and less important data in the resource fork.
> The "Macintosh Mistake," as you call it, was not providing
> extended attributes, but putting actual parts of the
> applications in there.
If you give people a system-provided mini database, people will use it.
There's no way to avoid that.
> macs. The bits of the resource fork that are not used for
> that -- such as extra type and creator information,
... not actually in the resource fork unless you're running on a MFS
filesystem, or AppleDouble and stuff like that.
>thumbnails,
> comments, icons, etc -- is useful, but not vital to the file,
> and not a "mistake."
Many users will violently disagree here. And of course, type and creator
info is bloody essential.
MfG Kai
-
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.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:27 EST