[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
process...
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.
Cheers,
David