I may be misunderstanding what you're saying, but it sounds like you're 
proposing that checkName:... would actually canonicalize the file name 
into a full path before checking it.

But then if I pass in "Seaside/Foo-Bar" (the case where I encountered 
the problem), how does it know the difference between the / in my 
filename and the other slashes in my path?

We certainly need to canonicalize the filenames in many places but I 
don't think this method is the correct candidate.  Is your reply an 
argument against including this fix for the time being?  It seems the 
system is in a more functional state with the fix than without...

Julian

Timothy Rowledge wrote:
> This method is on my list of clients for some wetwork. It seems to me 
> that whenever possible we should ask the OS to canonicalize the filename 
> and thus checkName... should be improved a little to make use of such a 
> prim.
> 
> On RISC OS for example there is a nice function that you pass a 
> candidate string and a bufffer. You get back the corrected name in the 
> buffer, canonicalized against any local dirs, paths, settings, locales 
> etc. I imagine a broadly similar api is likely on most OSs.
> 
> tim
> 
>