[lkml]   [2000]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: NTFS-like streams?

# 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's forks
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'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 <>

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.162 / U:1.812 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site