Re: PATCH: NSPathUtilities etc

[Sheldon Gill]

> Some more comments on NSPathUtilities.m. I think I'd be ready to commit
> this after addressing these comments.

Excellent!  I'd be happy to update my submission and work with you in it's 
integration.

> > /* Initialise all things required by this module */
> > void InitialisePathUtilities(void)

> 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.

> >       /* Finally we check and report problems... */
> >       if (gnustep_system_root == nil)
> >         {
> >           gnustep_system_root = internalise_path_Cstring( \
> >                                   stringify(GNUSTEP_INSTALL_PREFIX));
>
> Also, I think we should set GNUSTEP_LOCAL_ROOT and GNUSTEP_NETWORK_ROOT
> from the compiled in values if they are not found anywhere as well (as
> is done currently.)
>
> With those changes, people's current setups will work correctly without
> any changes.

Will add them in.

> > /**
> >  * 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.


Regards,
Sheldon