bug-gnustep
[Top][All Lists]
Advanced

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

Re:


From: Sheldon Gill
Subject: Re:
Date: Tue, 9 Mar 2004 13:09:35 +0800
User-agent: KMail/1.6.50

On Sun, 7 Mar 2004 22:52, richard@tiptree.demon.co.uk wrote:
> Sorry about the mess .... I'm away from home and trying to use a webmail
> system hope you can sort this out ...

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

I was simply trying to provide a concrete example. Although at an application 
level you will never want to know where something else is storing temporary 
files I can see situations where it is required for implementing system or 
developer tools and libraries.

An easy example, there should be a desktop tool to provide a way to clean temp 
space. For the X11 example, what I wanted to do was create a tool which 
snooped on unix domain sockets. A third example is multiple producer 
applications creating files which are consumed by another application.

> 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 can live with that. I'd also advocate adding a GSTemporaryFile() call which 
creates atomically a user only file with a random name.

Alternatively, we could go for GSSystemTemporaryDirectory() or similar which 
provides the base path for those that need it.

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

We can do this through the new GSSecureTemporaryDirectory() and friends.

Can we agree that layering functionality gives us benefits which are worth it?


Regards,
Sheldon




reply via email to

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