[alexandria-devel] Proposed addition of temporary file creation utilities

[Hans Hübner]

Nikodemus,

I've already packaged the functionality into a separate library:
http://netzhansa.com/temporary-file.html - I have some things to clean
up and improve before releasing it into Quicklisp.

The random state in that implementation is protected by a lock - The
overhead should be negligible, given that the lock is grabbed in the
context of a file operation.

Dealing with the umask has no place in this library.  "umask" is a
system-specific concept, and file security is something that is
orthogonal to temporary files.  If an application wishes to give its
temporary files different permissions than other files that it
creates, it should do so explicitly.

And besides, why put temporary files into a shared directory in the
first place?  The right way to deal with possible issues in this
respect is to create an application specific temporary directory that
is completely protected before starting the application, and
communicating that directory to the application by the way of the TEMP
or TMPDIR environment variable.  That is how Windows and OSX do it,
and it is much better than trying to protect files in a shared /tmp/
directory.  As if we did not have a hierarchical file system for a few
decades.

That said, I'm not particularly fond of having a separate library for
such a simple thing and I'd be glad to see it be merged to some other
utility type library that is not restricted to certain styles of
system interfaces (i.e. POSIX).

-Hans

On Wed, Apr 25, 2012 at 6:11 AM, Nikodemus Siivola
<nikodemus at random-state.net> wrote:
> I'm coming on the side of saying that this has a place in Madeira,
> (first version of which I'm releasing before the end of May.)
>
> Madeira can deal with the umask and thread-safety of *random-state*,
> whereas Alexandria has so far resisted unportable or implementation
> specific code -- and dealing with those two requires that.
>
> Umask could be degreed to simply be the process umask, which would be
> suboptimal but acceptable, but thread-safety is more serious -- though
> I suspect that parallel RANDOM calls should at worst produce degraded
> quality of random numbers, not corruption or errors, but every time
> someone assumes "this can't cause serious issues" a kitten dies, so...
>
> Cheers,
>
>  -- nikodemus