Sorry about the mess .... I'm away from home and trying to use a webmail system hope
you can sort this out ...
On 4 Mar 2004, at 06:58, David Ayers wrote:
Sheldon Gill wrote:
/**
* Returns the name of a directory in which temporary files can be
stored.<br/ >
* For unix-like systems this is usually '/tmp'.<br/ >
* For MS-Windows systems this is the system temporary directory,
often '%WINDIR%\TEMP\'.<br/ >
*/
NSString
*NSTemporaryDirectory(void)
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.
If it's not secure, it should be fixed.
Secondly, the OpenStep and Cocoa behaviour is simply to return the temporary directory.
That's incorrect ... on Cocoa (on my system) the behavior is to return a private
temporary directory '/private/tmp/501/TemporaryItems' where the '501' is my uid.
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".
We should *never* expect NSTemporaryDirectory() to tell us where X11 is storing its
temporary files ... that would be an undocumented and unportable feature. We would be
trying to do something that the api is not intended for.
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.
I strongly disagree ... the MacOS-X compatible way is to return a private temporary
directory. While it's true that the documentation doesn't say that the directory is
private/secure, we should try to maintain compatible behavior rather than introducing
a new incompatible one.
Thus it serves as the basis of all operations.
* If you want a secure directory in there write
MyTemporaryDirectory() which does the right things for your application and platform
* If you want a secure temp file write
MyCreateTempFile() which does the right things for your purposes
* If you want to find, use GSFindNamedFile( NSTemporaryDirectory(), ".X11-unix", nil)
or whatever
It does pave the way for a library of routines to do these things in various ways for
various platforms but I think this is a good thing.
Creating a single use temporary file under POSIX is best done by calling (f)open with
the create flag, limited mode and a difficult name to guess.
Doing the same conceptual thing under Win32 is different.
In short, I strove to make things more simple and straightforward. I feel this
generally leads to more robust code that's both easier to use and maintain.
I can see how one can derive this from the documentation. But IMO, this definitely
needs a transition period for code relying on the secureness of
NSTemporaryDirectory(). First we need a major release which introduces something like
a GSSecureTemporaryDirectory(), have NSTemporaryDirectory() return that same directory
and prominently announce that NSTemporaryDirectory() won't return a secured directory
but the system directory in future releases. We can then consider changing
NSTemporaryDirectory() for the following major release.
I believe we should try to make sure that the temporary directory *is* secure, and
document this behavvior, rather than introducing a different behavior than MacOS-X.
_______________________________________________
Bug-gnustep mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-gnustep
