[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