Re: fix inadequate Windows implementation of tmpfile

[Ben Pfaff]

Bruno Haible <address@hidden> writes:

> Here, it's debatable whether the tmpfile() function in MSVCRT is broken:
> On one hand, ISO C 99 says
>    "It should be possible to open at least TMP_MAX temporary files during
>     the lifetime of the program..."
> which isn't fulfilled, as you say, if the user doesn't have the permissions.
> (Btw, such situations can also occur on Unix! KDE becomes unusable when
> /tmp is full.)
>
> On the other hand, Microsoft's doc of tmpfile
>   http://msdn2.microsoft.com/en-us/library/x8x7sakw(VS.80).aspx
> and of tmpfile_s
>   http://msdn2.microsoft.com/en-us/library/b3dz6009(VS.80).aspx
> explicitly says
>   "The temporary file is created in the root directory."
>
> So, your replacement doesn't fulfill the Microsoft doc. Therefore, I think
> you should choose a different name for your function, since you want it
> to behave differently than the documented behaviour of tmpfile() on Windows.

I agree that the Windows implementation is, arguably, C99 and
POSIX compliant.  But I claim that it has an unreasonably poor
quality of implementation, bad enough that we should replace it.
If a Unix-like system implemented its tmpfile in a similar way,
by always attempting to create a file in the root directory and
failing if permissions were lacking, I imagine that we'd all
accept that this is a poor implementation that should be
replaced.

To me the Microsoft documentation seems like a red herring.  The
way I've always thought about Gnulib is that it allows a GNU
program to make assumptions about its environment that GNU
programmers find comfortable, by covering up the differences
where it is possible.  For example, GNU programmers find it
comfortable to assume that malloc(0) returns non-null, so Gnulib
helps with that.

> The _O_TEMPORARY flag is interesting. It appears to be portable to all
> versions of Windows since Woe95. What can you say about its reliability?
> The native tmpfile() uses this flag as well. Is a file created with tmpfile()
> on Windows deleted when you interrupt the program with Ctrl-C / Ctrl-Break?

I've only tested it under Wine, not under any version of Windows,
so I can't really say for sure.

There seems to be some kind of problem with
FILE_FLAG_DELETE_ON_CLOSE, with which _O_TEMPORARY is presumably
implemented, under Windows 95:
        http://cygwin.com/ml/cygwin-cvs/2003-q4/msg00025.html

In fact, it appears that FILE_FLAG_DELETE_ON_CLOSE works on NT
derivatives, not on the older Windows systems, based on the
has_delete_on_close definitions here (sorry about citing a patch
when a source file would probably be better, this is based on a
very quick search):
        http://www.cygwin.com/ml/cygwin-patches/2003-q1/msg00170.html

Where it works, it appears to be implemented such that it always
works, even if a program is terminated abruptly, based on what
I've read on the web.

>> I using the clean-temp module instead, as a
>> more portable solution, but then I needed to interpose upon
>> fclose (and perhaps close as well) to delete the temporary file
>> when it was closed, which quickly turned into a mess.
>
> Can you elaborate, please? clean-temp guarantees that the file will be
> removed in most cases. You want it removed earlier, as soon as the fclose
> happens? To save disk space?

Yes: PSPP uses temporary files for transposing big matrices,
out-of-core merge sorting, and so on, so it's a good idea to free
up disk space when it can.
-- 
Ben Pfaff 
address@hidden
http://benpfaff.org