[Top][All Lists]

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

Re: NSSearchPathForDirectoriesInDomains and non-existing directories

From: David Ayers
Subject: Re: NSSearchPathForDirectoriesInDomains and non-existing directories
Date: Mon, 24 Oct 2005 12:44:51 +0200
User-agent: Mozilla Thunderbird 1.0.2 (X11/20051002)

Andriy Gapon schrieb:

> 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 remember looking into this exact issue once but I can't remember that
I came to a conclusion of what "the right thing" to do is.  I don't have
OS X but IIRC I was told that the directory was created together with
the account.  So what ever the behavior is, I guess it can be viewed as
undefined as it doesn't really exist on OS X without manipulation of the
expected setup.

If we chose #1 then it would be the application's (or non-core
library's) job to create the directory if it doesn't exist before
writing to it.  I think that would just push the "bug" to different place.

Yet if we chose #2 then we could be cluttering the home directory of say
a packaging user who implicitly runs gnustep programs during the build

But I think we already do that for user defaults anyway and that's what
I thought could be handled by setting GNUSTEP_USER_DIR.

So I would lean toward #2 right now... but I have a gut feeling I'm
still missing some implication.


reply via email to

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