bug-gnustep
[Top][All Lists]
Advanced

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

Re: PATCH: NSPathUtilities etc


From: Adam Fedor
Subject: Re: PATCH: NSPathUtilities etc
Date: Wed, 3 Mar 2004 13:57:22 -0700


On Wednesday, March 3, 2004, at 12:54 AM, Sheldon Gill wrote:

I'd like to keep support for the root .GNUsteprc file as well, at least
until we decide to depreciate it.

I thought that now was right time to do so. It does not add functionality,
but the same level is provided by the new GNUstep.conf along with other
benefits. One might consider the new configuration file a sort of upgrade of
the old one, albeit one which requires changes and moving the file.

I think having a root .GNUsteprc which can over-ride GNUstep.conf makes things
more complex without giving us any benefits.


Yes, that's true, but I'd like to keep one release cycle between depreciating it and removing it. I bet no one is actually using it, but now-days I'm often surprised by the number of situations GNUstep is used in.


Why did you take out the creation of a secure subdirectory of temp?

This is a bigger question.

Firstly, the existing code isn't really secure. You can circumvent it. I
looked at changing that but things start getting quite complex.

Secondly, the OpenStep and Cocoa behaviour is simply to return the temporary
directory.

Now, what is the right behaviour from an API perspective? Well, on one hand we want a place where we can create temporary files in a secure and safe way. Often, the goal is a temporary file. Pure and simple. No need for a whole
directory.
On the other hand, sometimes we want to discover where {temp} actually is. For
example, if I want to find "/tmp/.X11-unix".

Additionally, there are systems which use extended attributes and capabilities
for more secure/flexible behaviour.

In light of these things, I think that the right thing for
NSTemporaryDirectory() to do is to return the path to the temporary
directory.



Well I agree. I didn't even know the function was doing that until I read the source, so it definitely was not very transparent.





reply via email to

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