lkml.org 
[lkml]   [2000]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: NTFS-like streams?
    Date
    In article <399555EB.F29C5937@flyingbuttmonkeys.com>,
    Michael Rothwell <rothwell@flyingbuttmonkeys.com> wrote:
    >Rik van Riel wrote:
    >
    >> When you _do_ want to have these things transferred, you can
    >> use a modified tar (or cpio or pax) archive format. Just like
    >> the "standard tar" stores the normal unix attributes, it should
    >> store the extended attributes.
    >
    >Yes.

    Note that this is something that the Mac community (and others) have
    handled for a long time.

    The same way unix users use "tar.gz" files, mac users use their own
    zipped files ("binhex" etc). It's not all that different, in the end.

    Doing this kind of support properly in Linux would probably imply that
    we should add another bit to the "mode" flags to indicate "complex
    file", so that programs could test this properly without having to try
    to do a readdir on every single regular file. The current "stat64"
    interface does have 32 bits for this, of which we actuall yonly use 16
    for the historical unix st_stat.

    Note that the alternative (that I think AUX used for doing the Mac
    filesystem: it was obviously quite important to them) is to really show
    resource forks as directories all the time and not even have the notion
    of a "complex file" at all. The difference from a VFS perspective in
    Linux is pretty much negligible: whether you open

    ~/my-complex-file/default

    or whether you can open the complex file directly (ie an "implied"
    default fork by just opening ~/my-complex-file directly) is not
    something the VFS interface should really care about. However, I don't
    think it's a very nice user-interface to force the "files with resource
    forks are always seen as directories" notion upon users. It defeats the
    _nice_ properties of resource forks (ie not forcing people to be aware
    of the secondary data).

    Linus

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