[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSSearchPathForDirectoriesInDomains and non-existing directories

From: Richard Frith-Macdonald
Subject: Re: NSSearchPathForDirectoriesInDomains and non-existing directories
Date: Tue, 25 Oct 2005 13:17:53 +0100

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.


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)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]