Re: NTFS-like streams?

From: Mo McKinlay (mmckinlay@gnu.org)
Date: Sat Aug 12 2000 - 02:40:28 EST


# Of course, it will break backward compatibility (for normal
# open()/read()/...) on some files that programs are supposed to read
# without any way to detect "trailing garbage" (text, for example, will have
# all streams appended but, say, image files will remain usable with
# existing software).

cat file1 file2 > file3

Net result, file3 contains:

file1
file1's forks
file2
file2's forks

In that order.

Even if they were arranged into the right order, it probably wouldn't be
what you want. Considering that a common use for such forks would be to
provide extra (optional, of course) file-typing information, where would
you take the information from? file1? file2? How would you cope with more
than one fork with the same name, neither of which were written out to the
file that you're dealing with?

The effects of doing this are probably more harmful than ignoring the
forks and letting whichever applications use them fall back to sensible
defaults (after all, you're creating a new file).

So, this method doesn't work as well from either side - forks aren't
independent of the main stream (adding an icon to C source code would
cause your compiler to bitch for hours, for example), and forks get munged
when you combine files.

And you'd have to handle the cases where you seek to the end of the file
and append data to it...you'd have continually move the forks out of the
way - which would give you a nasty speed penalty.

Breaking backward compatibility is *bad*. In this case, it's much better
to have a specific API for dealing with the streams, and work on the
assumption that a stream may get clobbered, than break backwards
compatibility for the sake of something which wouldn't get used all that
much for a fair while (even if other operating systems did implement it,
it'd still be a while before it caught on proper).

-- 
Mo McKinlay             Chief Software Architect          inter/open Labs
-------------------------------------------------------------------------
GnuPG Key: pub  1024D/76A275F9 2000-07-22 Mo McKinlay <mmckinlay@gnu.org>

- 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