/**
* Returns loginName's home directory as an NSString object.
*/
s = Win32GetUserProfileDirectory(loginName);
Does this look at HOMEPATH or USERPROFILE? Should we allow the user to
override this with HOMEPATH, etc, if not?
At the moment it looks at HOMEPATH first, followed by USERPROFILE. These are
just environment variables and so can be overridden by the user.
I have code to get the real home path from API calls coming...
that'll mean no need for environment variables...
My -make changes follow the same logic but issue a warning about potential
problems with spaces in the path.
/**
* 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.
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.
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.