Re: NSSearchPathForDirectoriesInDomains and non-existing directories

[Sheldon Gill]

Andriy Gapon wrote:
> Let me shoot the question first - what is the rationale behind
> NSSearchPathForDirectoriesInDomains not returning directory name if the
> directory does not exist ? Esp. so if NSUserDomainMask is used ?

This is the way the function was defined to work a long time ago. In other 
words, it behaves as specified.

The idea in general terms is that you are asking for a location. If that 
location doesn't exist, it returns <nil> rather than an exception.
The location may not exist because you're running on an old or new version 
where it doesn't exist anymore. Things change.

Calling code is supposed to know and respect this.

> In my opinion what NSSearchPathForDirectoriesInDomains() does now is
> incorrect. I don't have an opportunity to verify how this function
> behaves in original NeXTStep or how it behaves in OS X framework, but I
> think GNUstep behavior is unreasonable.
>
> I see two possible ways of improving NSSearchPathForDirectoriesInDomains():
>
> 1. just return the names and let calling code worry if the directories
> actually exist
> 2. try to create non-existing directories in the list and only if that
> fails that remove them from the list
>
> I personally am torn between simplicity and elegance of #1 and
> user-friendliness of #2.

I think you've mis-diagnosed the behaviour problem. 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.

There is some sense in (1) but the question arises: "what do you do when the 
specified directory doesn't make sense on the current system?"   You'd end up 
needing to handle an exception or error return anyway.


Regards,
Sheldon