Re: [9fans] frogs and osx
> Using u9fs to access my mac I find I cannot see directories (folders)[color=blue]
> 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™ ?[/color]
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
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:[color=blue][color=green]
> > 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™ ?[/color]
>
> 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
>
>[/color]
Re: [9fans] frogs and osx
On 2008-Jan-3, at 19:29 , Russ Cox wrote:
[color=blue]
> In addition to NUL, surely / should be illegal!
> I certainly wouldn't want \n in file names; \r seems just too close.[/color]
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
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:[color=blue]
>
> On 2008-Jan-3, at 19:29 , Russ Cox wrote:
>[color=green]
> > In addition to NUL, surely / should be illegal!
> > I certainly wouldn't want \n in file names; \r seems just too close.[/color]
>
> 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 ...
>[/color]
Re: [9fans] frogs and osx
On 2008-Jan-4, at 00:31 , Bruce Ellis wrote:
[color=blue]
> but filenames created
> from buggy stuff die dead, as they should.[/color]
what's buggy? '/' had merit. what else?
Re: [9fans] frogs and osx
On 2008-Jan-4, at 00:31 , Bruce Ellis wrote:
[color=blue]
> 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.[/color]
We are arguing different things. EOL conventions are religion. Kernel
delimiters are just code.
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 <lyndon@orthanc.ca> wrote:[color=blue]
>
> On 2008-Jan-4, at 00:31 , Bruce Ellis wrote:
>[color=green]
> > but filenames created
> > from buggy stuff die dead, as they should.[/color]
>
> what's buggy? '/' had merit. what else?[/color]
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 <lyndon@orthanc.ca> wrote:[color=blue]
>
> On 2008-Jan-4, at 00:31 , Bruce Ellis wrote:
>[color=green]
> > 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.[/color]
>
> We are arguing different things. EOL conventions are religion. Kernel
> delimiters are just code.
>[/color]
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
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 <steve@quintile.net> wrote:[color=blue]
> 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
>[/color]
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:
[color=blue]
>
> On 2008-Jan-3, at 19:29 , Russ Cox wrote:
>[color=green]
>> In addition to NUL, surely / should be illegal!
>> I certainly wouldn't want \n in file names; \r seems just too close.[/color]
>
> 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 ...[/color]
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:
[color=blue]
> 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:
>[color=green]
>>
>> On 2008-Jan-3, at 19:29 , Russ Cox wrote:
>>[color=darkred]
>>> In addition to NUL, surely / should be illegal!
>>> I certainly wouldn't want \n in file names; \r seems just too close.[/color]
>>
>> 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 ...[/color]
>[/color]
