[9fans] frogs and osx

[9fans] frogs and osx

[Steve Simon]

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<cr> whiel <cr> 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 <nul>
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

Re: [9fans] frogs and osx

[Russ Cox]

> 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<cr> whiel <cr> 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 <nul>
> 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

Re: [9fans] frogs and osx

[Bruce Ellis]

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 <rsc@swtch.com> 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<cr> whiel <cr> 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 <nul>
> > 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
>
>

Re: [9fans] frogs and osx

[Lyndon Nerenberg]

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 ...

Re: [9fans] frogs and osx

[Bruce Ellis]

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 <lyndon@orthanc.ca> 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 ...
>

Re: [9fans] frogs and osx

[Lyndon Nerenberg]

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?

Re: [9fans] frogs and osx

[Lyndon Nerenberg]

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.

Re: [9fans] frogs and osx

[Bruce Ellis]

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

On Jan 4, 2008 6:37 PM, Lyndon Nerenberg <lyndon@orthanc.ca> 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?

Re: [9fans] frogs and osx

[Bruce Ellis]

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 <lyndon@orthanc.ca> 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.
>

Re: [9fans] frogs and osx

[Steve Simon]

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

Re: [9fans] frogs and osx

[Bruce Ellis]

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
"shit happens" then the world falls apart.

brucee

On Jan 4, 2008 9:17 PM, Steve Simon <steve@quintile.net> 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
>

Re: [9fans] frogs and osx

[Pietro Gagliardi]

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 ...

Re: [9fans] frogs and osx

[underspecified]

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 ...
>