[lkml]   [2000]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: NTFS-like streams?
   Date: Fri, 11 Aug 2000 22:34:12 -0400
From: Michael Rothwell <>

> 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?

For example, a "make depend" script, which only copies "the default
fork". So any information that was attached via "extended attributes"
or "named forks" will get lost in that case.

> This was made most obvious on the Apple Macintosh, where you
> had to use ugly tools like binhex whenever you tried moving a file from
> a Macintosh to some other platform (like an FTP server) lest you make
> data file or an executable useless because you managed to lose one of
> its resource forks.

The "Macintosh Mistake," as you call it, was not providing
extended attributes, but putting actual parts of the
applications in there. Old Mac apps actually store code
fragments, menu text, etc. in the resource fork, which was
a way to provide demand paging on the cheap for those 512K
macs. The bits of the resource fork that are not used for
that -- such as extra type and creator information, thumbnails,
comments, icons, etc -- is useful, but not vital to the file,
and not a "mistake."

There were Mac applications which stored data in the resource fork for
data files? And guess what? It was lost when you ftp'ed them.

And yet, I was just talking to some GNOME folks at the OLS, and I had to
explain to them again and again why ditching libxml and storing
application data in "named forks" was a disastrous idea. It seems that
a lot of application programmers "don't get it", and want to basically
perpetuate the "Macintosh Mistake". That is, storing data in fields
that should ONLY be used for metadata.

> Because of the above problems, using extended data is usually at *least*
> as brittle. The right answer in many instances is to make a easy-to-use
> *user* *library* that allows applications to have the functionality of
> being able to easily store multiple resource forks, but which looks to
> the system like a single file.

Like the Windows Registry? Or what I was suggesting
earlier -- BeOS-type accessor functions allowing
access to extended attributes for a file?

No, like GNOME's libxml. Which, granted, is too slow. We need to have
a binary data file format which can efficiently handle multiple streams
in a single file. But this should be done in user-mode, as a library
which any application can use. And what it should store is a file,
which can be seamlessly moved from OS to OS, including other Unix
systems that don't have named streams, without making your data files

- Ted

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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