[9fans] frogs and osx - Plan9

This is a discussion on [9fans] frogs and osx - Plan9 ; Hi, Using u9fs to access my mac I find I cannot see directories (folders) that have their own specific icon. This turns out to be because these directories contain a file Icon whiel is ASCII 13, and /sys/src/9/port/chan.c:1656 defines the ...

+ Reply to Thread
Results 1 to 13 of 13

Thread: [9fans] frogs and osx

  1. [9fans] frogs and osx

    Hi,

    Using u9fs to access my mac I find I cannot see directories (folders)
    that have their own specific icon.

    This turns out to be because these directories contain a file
    Icon whiel is ASCII 13, and /sys/src/9/port/chan.c:1656
    defines the frogs illegal in filenames to include carriage return.

    Why does frogs contain these latters, My feeling is that only
    should be illegal, perhaps these are a hangover from pre utf-8
    days?

    Perhaps there is a good reason for not allowing such characters,
    I can see that creating such files should be discouraged but
    failing a read(2) of a directory containing such files seems extreme.

    Is it historic or there for a very good reason™ ?

    -Steve

  2. Re: [9fans] frogs and osx

    > Using u9fs to access my mac I find I cannot see directories (folders)
    > that have their own specific icon.
    >
    > This turns out to be because these directories contain a file
    > Icon whiel is ASCII 13, and /sys/src/9/port/chan.c:1656
    > defines the frogs illegal in filenames to include carriage return.
    >
    > Why does frogs contain these latters, My feeling is that only
    > should be illegal, perhaps these are a hangover from pre utf-8
    > days?
    >
    > Perhaps there is a good reason for not allowing such characters,
    > I can see that creating such files should be discouraged but
    > failing a read(2) of a directory containing such files seems extreme.
    >
    > Is it historic or there for a very good reason™ ?


    In addition to NUL, surely / should be illegal!
    I certainly wouldn't want \n in file names; \r seems just too close.
    In general, I'm quite happy that file names are guaranteed
    not to contain such difficult characters. There's very little
    benefit to be had by allowing them, and they complicate many
    things (witness xargs -0 on Unix).

    A better workaround for this particular problem would be
    for u9fs to rewrite the name or omit that entry entirely.

    Russ


  3. Re: [9fans] frogs and osx

    my recollection is frogs was for files created by mistake.
    nothing to do with UTF-8. as for ICON\r ... can we call
    that consistency by obscurity. after all it is not to hard
    at all to subvert but a user won't, click click click nuh.

    also, i remember well when ' ' was snuck out to see if
    anyone noticed. it stuck.

    brucee

    On Jan 4, 2008 1:29 PM, Russ Cox wrote:
    > > Using u9fs to access my mac I find I cannot see directories (folders)
    > > that have their own specific icon.
    > >
    > > This turns out to be because these directories contain a file
    > > Icon whiel is ASCII 13, and /sys/src/9/port/chan.c:1656
    > > defines the frogs illegal in filenames to include carriage return.
    > >
    > > Why does frogs contain these latters, My feeling is that only
    > > should be illegal, perhaps these are a hangover from pre utf-8
    > > days?
    > >
    > > Perhaps there is a good reason for not allowing such characters,
    > > I can see that creating such files should be discouraged but
    > > failing a read(2) of a directory containing such files seems extreme.
    > >
    > > Is it historic or there for a very good reason™ ?

    >
    > In addition to NUL, surely / should be illegal!
    > I certainly wouldn't want \n in file names; \r seems just too close.
    > In general, I'm quite happy that file names are guaranteed
    > not to contain such difficult characters. There's very little
    > benefit to be had by allowing them, and they complicate many
    > things (witness xargs -0 on Unix).
    >
    > A better workaround for this particular problem would be
    > for u9fs to rewrite the name or omit that entry entirely.
    >
    > Russ
    >
    >


  4. Re: [9fans] frogs and osx


    On 2008-Jan-3, at 19:29 , Russ Cox wrote:

    > In addition to NUL, surely / should be illegal!
    > I certainly wouldn't want \n in file names; \r seems just too close.


    Pathological egregiousness?

    There is only one true separator, and that is '/'. In the context of
    pathnames, '/' is NUL as per C strings. NUL in pathnames is silly, but
    allowed, as per pathnames.

    It makes no sense, but if you can push a NUL into a pathname, you
    should deal with the result. It's a pity the intermediate code has to
    do so as well ...

  5. Re: [9fans] frogs and osx

    not at all, pragmatic.excluding crap from filenames was and still is good.
    if you want to vote '\r' as "not a mistake" you can. but filenames created
    from buggy stuff die dead, as they should.

    brucee

    On Jan 4, 2008 6:24 PM, Lyndon Nerenberg wrote:
    >
    > On 2008-Jan-3, at 19:29 , Russ Cox wrote:
    >
    > > In addition to NUL, surely / should be illegal!
    > > I certainly wouldn't want \n in file names; \r seems just too close.

    >
    > Pathological egregiousness?
    >
    > There is only one true separator, and that is '/'. In the context of
    > pathnames, '/' is NUL as per C strings. NUL in pathnames is silly, but
    > allowed, as per pathnames.
    >
    > It makes no sense, but if you can push a NUL into a pathname, you
    > should deal with the result. It's a pity the intermediate code has to
    > do so as well ...
    >


  6. Re: [9fans] frogs and osx


    On 2008-Jan-4, at 00:31 , Bruce Ellis wrote:

    > but filenames created
    > from buggy stuff die dead, as they should.


    what's buggy? '/' had merit. what else?

  7. Re: [9fans] frogs and osx


    On 2008-Jan-4, at 00:31 , Bruce Ellis wrote:

    > not at all, pragmatic.excluding crap from filenames was and still is
    > good.
    > if you want to vote '\r' as "not a mistake" you can. but filenames
    > created
    > from buggy stuff die dead, as they should.


    We are arguing different things. EOL conventions are religion. Kernel
    delimiters are just code.

  8. Re: [9fans] frogs and osx

    buggy is writing crap to a buffer ... like 0x80740378. nuke it.

    On Jan 4, 2008 6:37 PM, Lyndon Nerenberg wrote:
    >
    > On 2008-Jan-4, at 00:31 , Bruce Ellis wrote:
    >
    > > but filenames created
    > > from buggy stuff die dead, as they should.

    >
    > what's buggy? '/' had merit. what else?


  9. Re: [9fans] frogs and osx

    NO! a frog is a mistake. '\n' and '\r' are both frogs so where did
    you get the EOL thing from. i want neither in my filenames.
    if you do then change your copy of the code. or make up a new
    reason not to. make your own island of tranquility.

    brucee

    On Jan 4, 2008 6:45 PM, Lyndon Nerenberg wrote:
    >
    > On 2008-Jan-4, at 00:31 , Bruce Ellis wrote:
    >
    > > not at all, pragmatic.excluding crap from filenames was and still is
    > > good.
    > > if you want to vote '\r' as "not a mistake" you can. but filenames
    > > created
    > > from buggy stuff die dead, as they should.

    >
    > We are arguing different things. EOL conventions are religion. Kernel
    > delimiters are just code.
    >


  10. Re: [9fans] frogs and osx

    I take onboard all the commeonst made, and I am happy to
    code my own island of mutant frogs, however I wonder if there
    is a middle ground.

    Firstly I don't understand why the frogs are such a big problem,
    on plan9 at least a file with a \r in it appears as a
    , and this
    is a visible and easily typeable character, its true things where
    more awkward on ADM3As, but that was then.

    My biggest objection to the current code is a read of a directory balks
    at the \r and fails. Would it be better to hack the kernel to allow a
    read of directories containing \r and walks through them, but not
    allow read/write/stat/wstat.

    This would mean that such files are off limits but you can still access
    other files in the directory and those below - this feels rather
    non-othogonal maybe its a reasonable compromise.

    I could indeed hack u9fs but what to change the
    to, \r perhaps, but
    that feels pretty horrid too.

    Is there a palatable solution?

    -Steve

  11. Re: [9fans] frogs and osx

    Sure,

    I think it's a mistake for a server to throw you frogs. But no reason
    (within reason) for the library to up-chuck on one. But take care
    where you walk. If every protocol "violation" had to be treated as
    "**** happens" then the world falls apart.

    brucee

    On Jan 4, 2008 9:17 PM, Steve Simon wrote:
    > I take onboard all the commeonst made, and I am happy to
    > code my own island of mutant frogs, however I wonder if there
    > is a middle ground.
    >
    > Firstly I don't understand why the frogs are such a big problem,
    > on plan9 at least a file with a \r in it appears as a
    > , and this
    > is a visible and easily typeable character, its true things where
    > more awkward on ADM3As, but that was then.
    >
    > My biggest objection to the current code is a read of a directory balks
    > at the \r and fails. Would it be better to hack the kernel to allow a
    > read of directories containing \r and walks through them, but not
    > allow read/write/stat/wstat.
    >
    > This would mean that such files are off limits but you can still access
    > other files in the directory and those below - this feels rather
    > non-othogonal maybe its a reasonable compromise.
    >
    > I could indeed hack u9fs but what to change the
    > to, \r perhaps, but
    > that feels pretty horrid too.
    >
    > Is there a palatable solution?
    >
    > -Steve
    >


  12. Re: [9fans] frogs and osx

    It's also a pity that you'll need to rewrite your code to handle two
    different types of delimiters then, or add a dellim argument like in
    Brdstr. The UNIX philosophy says to do what's smaller and faster, not
    what's better (which is why I don't like it).

    I haven't seen a reason to use the format "icon\rname" in an OS X
    directory. Why not just store the information in the
    folder's .DS_store file (which has every other Finder credential)?
    Ahh, the mysteries of my iMac...

    On Jan 4, 2008, at 2:24 AM, Lyndon Nerenberg wrote:

    >
    > On 2008-Jan-3, at 19:29 , Russ Cox wrote:
    >
    >> In addition to NUL, surely / should be illegal!
    >> I certainly wouldn't want \n in file names; \r seems just too close.

    >
    > Pathological egregiousness?
    >
    > There is only one true separator, and that is '/'. In the context
    > of pathnames, '/' is NUL as per C strings. NUL in pathnames is
    > silly, but allowed, as per pathnames.
    >
    > It makes no sense, but if you can push a NUL into a pathname, you
    > should deal with the result. It's a pity the intermediate code has
    > to do so as well ...



  13. Re: [9fans] frogs and osx

    Just to add my two cents, I had a bit of fun trying to identify the
    cause of some strange behavior in Acme SAC for OS X.
    The home directory started refusing to display the contents of my home
    directory. The culprit? An icon file had snuck in
    and its carriage return was giving Acme SAC a headache. I agree that
    OS X probably shouldn't store icons in that manner
    (even the applications aren't silly enough to do that), but this is
    something we might just have to work around. Not being
    able to access directories with icons is a large price to pay to take
    the high ground ...

    --underspecified

    On Jan 4, 2008, at 8:22 PM, Pietro Gagliardi wrote:

    > It's also a pity that you'll need to rewrite your code to handle two
    > different types of delimiters then, or add a dellim argument like in
    > Brdstr. The UNIX philosophy says to do what's smaller and faster,
    > not what's better (which is why I don't like it).
    >
    > I haven't seen a reason to use the format "icon\rname" in an OS X
    > directory. Why not just store the information in the
    > folder's .DS_store file (which has every other Finder credential)?
    > Ahh, the mysteries of my iMac...
    >
    > On Jan 4, 2008, at 2:24 AM, Lyndon Nerenberg wrote:
    >
    >>
    >> On 2008-Jan-3, at 19:29 , Russ Cox wrote:
    >>
    >>> In addition to NUL, surely / should be illegal!
    >>> I certainly wouldn't want \n in file names; \r seems just too close.

    >>
    >> Pathological egregiousness?
    >>
    >> There is only one true separator, and that is '/'. In the context
    >> of pathnames, '/' is NUL as per C strings. NUL in pathnames is
    >> silly, but allowed, as per pathnames.
    >>
    >> It makes no sense, but if you can push a NUL into a pathname, you
    >> should deal with the result. It's a pity the intermediate code has
    >> to do so as well ...

    >



+ Reply to Thread