Messages in this thread | | | Date | Sat, 12 Aug 2000 08:40:28 +0100 (GMT) | From | Mo McKinlay <> | Subject | Re: 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 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/
| |