lkml.org 
[lkml]   [2000]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    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
    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/

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