[9fans] HFS is a pain in the neck. - Plan9

This is a discussion on [9fans] HFS is a pain in the neck. - Plan9 ; HFS (and derivative) volumes contain one or both of the folloing directories with astoundingly anti-social names: ␀␀␀␀HFS+ Private Data .HFS+ Private Directory Data (that's a at the end of the last one). This is an awful hack to support hard ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: [9fans] HFS is a pain in the neck.

  1. [9fans] HFS is a pain in the neck.

    HFS (and derivative) volumes contain one or both of the folloing
    directories with astoundingly anti-social names:
    ␀␀␀␀HFS+ Private Data
    .HFS+ Private Directory Data
    (that's a at the end of the last one). This is an awful hack
    to support hard links. There may be others (I think at some point
    Apple changed the four nuls to something even more insane).
    Inferno's #U and 9vx's #Z don't turn these up; p9p does.

    These are a little worse than the Icon junk discussed a few
    months ago becuase they're on every HFS volume (as opposed to
    the Icons, which you can just not store that way), but still easy
    enough to just ignore most of the time (they're only in the root,
    after all), and despite the grossness, most of the tools can cope.

    vac will send this all to venti just fine. using vacfs (on Plan 9)
    to view the results doesn't work so well:
    : root; pwd
    /n/vac/2008/0718
    : root; lf
    ls: .: bad character in file name: '.HFS+ Private Directory Data
    '
    : root; lf Library
    : root; lf Users
    .DS_Store .localized Shared/ a* anthony/ dtipson/

    I haven't figured out how to get vac -e to skip all these yet, nor
    am I really keen to guess what the full set is. So the question:

    Is there a reason for the alternate #U/#Z vs. p9p behavior? Are
    there known cases where the p9p version is used/benificial? I'd
    like vac to simply not see these files and not send them to venti.

    Stupid HFS. I wish I had figured this out about a week ago,
    before I set up my new laptop.

    Anthony



  2. Re: [9fans] HFS is a pain in the neck.

    Both the vac file format and p9p can handle files
    that Plan 9 cannot. Other than anti-social characters
    in file names, they also handle symbolic links. There are
    people who use vac and p9p but have never used Plan 9.
    Imposing Plan 9's restrictions on non-Plan 9 users seems odd
    and certainly isn't a way to attract users.

    When this came up with u9fs, the solution was to treat
    u9fs as the boundary between the cleaner Plan 9 world
    and the outside world: it's u9fs's responsibility to keep
    the bad names out. Since the vac format already includes
    many hooks to represent Unix and MS-DOS and other kinds
    of non-Plan 9 file information, I think of vacfs as straddling
    the same boundary that u9fs does.

    Especially now that there is an unvac, it seems to me that
    the right thing to do is make vacfs skip over the paths that
    it cannot reliably report back. The change is minimal: in
    vacfs.c:/^vacdirread, in the for loop, add something like

    if(i == 0)
    break;
    + if(isfrogged(vd.elem)){
    + vdcleanup(&vd);
    + continue;
    + }
    n = vacstat(f->file, &vd, (uchar*)p, cnt-nb);

    along with a suitable isfrogged() function and a copy of the
    isfrog table from the kernel.

    If you were feeling more ambitious, you could use the
    defrog and enfrog routines from u9fs to translate the
    names into Plan 9-acceptable ones.

    Russ



  3. Re: [9fans] HFS is a pain in the neck.

    Ah. You're right, of course. The critical bit I missed was that
    it's Plan 9 complaining, not vacfs (per se) or even 9p. I can't
    test vacfs on the Mac right now (9pfuse isn't getting along
    well with macfuse), but '9p ls' shows the full listing for /
    complete with anti-social files.

    It would be nice if Plan 9's vacfs were a bit more helpful in
    this regard. I'll work up a patch soon.

    Anthony



+ Reply to Thread