Messages in this thread | | | Date | Sat, 12 Aug 2000 11:13:36 -0400 | From | "Theodore Y. Ts'o" <> | Subject | Re: NTFS-like streams? |
| |
Date: Fri, 11 Aug 2000 22:34:12 -0400 From: Michael Rothwell <rothwell@flyingbuttmonkeys.com>
> 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. *surprise*.
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 useless.
- Ted
- 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/
| |