Re: NSSearchPathForDirectoriesInDomains and non-existing directories

[Richard Frith-Macdonald]

On 2005-10-25 09:14:04 +0100 David Ayers <address@hidden> wrote:

> Sheldon Gill schrieb:
> > It isn't in
> > NSSearchPath() but rather the calling code. Creation of a path isn't and
> > shouldn't be the responsibility of NSSearchPath(). That needs to be
> > handled elsewhere. Generally it is, by the way.
>
> Indeed there are two issues at hand.
>
> 1.) NSColorList has to deal with NSSearchPath returning an empty array.

Yes.

> 2.) creating the expected user directory layout, and creating it "in
> time" for such usage as 1.) which I believe implies:
>   a.) We created it when sourcing GNUstep.[csh] (just kidding :-) )
>   b.) Creating the directory layout in +[NSObject initialize] or
>   c.) auditing core for NSSearchPath usage and calling an "internal"
> function/macro to create them just before the relevant invocations.

Perhaps there is a reason why directories don't exist ... so NSColorList 
should recognize that the directory does not exist, and return NO.
What about if the directory exists but is not writable? ... NSColorList 
needs to cope with that case too.  So, since code generally needs to be able 
to deal with error conditions, I'm not sure there is a compelling aregument 
to say we should force directories to exist by creating them.

That being said, I can see how useful automatically creating directories 
could be, and we could make the behavior configurable.  If we are going to 
do that, the obvious point to do it is when path lookups are initialised 
(NSPathUtilities.m)