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

    On Sun, 13 Aug 2000, Alan Cox wrote:

    > > But "tar" won't even _see_ the thing. Unless "tar" starts to know about
    > > S_IFCOMPLEX. In which case it's a non-issue.
    > oh wonderful. So you've just broken my backup scripts. Congratulations.


    Calm down a moment, and THINK.

    How hard do you think it is to make the tar-test that does

    if (S_ISDIR(st->st_mode)) {
    ... traverse into directories ..

    instead be

    #ifdef S_ISCOMPLEX
    #define CAN_TRAVERSE(x) (S_ISCOMPLEX(x) || S_ISDIR(x))
    #define CAN_TRAVERSE(x) (S_ISDIR(x))


    if (CAN_TRAVERSE(st->st_mode)) {
    .. traverse into directories ..

    and suddenly tar _can_ handle resource forks. Sure, you'll need some extra
    logic to handle the complex files data too, but really, Alan.

    What's the advantage, I hear you say?

    The above will work on HFS. But so will the current "tar". Resource forks
    and all.

    The above will -also- work on NTFS. And the current setup will never do

    > tar is already backing up my HFS test partition, including the resource
    > forks.

    ..and it can do so.

    The thing is, right now resource forks are only exported on HFS. As far as
    I know, the Linux NTFS driver doesn't even try. But people are starting to
    be more and more interested in supporting NTFS in a real way, rather than
    the partial support it has now. You-know-who etc.

    Quite frankly, _eventually_ we'll have to bite the bullet and handle
    resource forks. Maybe HFS will continue to use the current setup. Who
    knows? But wouldn't it be nice to have a unified way of handling it? And
    complain all you like, but the HFS way just cannot be the unified way.

    There are actually problems with the current HFS hackery: one of the
    problems is that because it splits things up in different directories, you
    have multiple dentries pointing to the same inode. That's fine: the dentry
    code has no trouble with that per se (hard links), but I suspect it causes
    races on create/remove.

    At the very least, I hope the virtual ".resource" directory is the same
    physical inode as the directory it resides in, because otherwise the basic
    "dir->i_sem" concurrency protection simply won't work.

    (To me it looks like that isn't the case. Race city. Nobody probably
    cares, but it's an example of the fact that HFS is actually buggy as it is
    implemented right now. Exactly because the VFS layer doesn't understand
    what it is that HFS is trying to do).

    Do you see the problem now? Is pointing you to a real bug enough?


    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.022 / U:220.436 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site