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 _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
