Sender: vheyndri AT rug DOT ac DOT be
Message-Id: <3503A31D.5DE2@rug.ac.be>
Date: Mon, 09 Mar 1998 09:06:53 +0100
From: Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
Mime-Version: 1.0
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Cc: DJ Delorie <dj AT delorie DOT com>, djgpp-workers AT delorie DOT com
Subject: Re: Temporary files considered unsafe
References: <Pine DOT SUN DOT 3 DOT 91 DOT 980308143758 DOT 22686h-100000 AT is>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

Eli Zaretskii wrote:
> 
> A discussion on gnu.utils.bug caused me to look at how safe are our
> temporary files in a multi-processing environment (e.g., Windows or when
> the temporray directory is shared over a network).  It turns out they are
> unsafe.  (Maybe that's the reason we cannot compile in two different DOS
> boxes at the same time?)

[snip]
> --- src/libc/ansi/stdio/tmpfile.c       Fri Mar  6 15:38:10 1998
[snip]
> --- 1,58 ----
>   FILE *
>   tmpfile(void)
>   {
> +   int  temp_fd;
>     FILE *f;
> !   char *temp_name = tmpnam(0);
> !   char *n_t_r = (char *)malloc(L_tmpnam);
> 
> !   if (!n_t_r)
>       return 0;
> 
> !   /* We could have a race condition, whereby another program
> !      (in another virtual machine, or if the temporary file is
> !      in a directory which is shared via a network) opens the
> !      file returned by `tmpnam' between the call above and the
> !      moment when we actually open the file below.  This loop
> !      retries the call to `tmpnam' until we actually succeed
> !      to create the file which didn't exist before.  */
> !   do
> !     temp_fd = _creatnew(temp_name, 0, SH_DENYRW);
> !   while (temp_fd == -1 && (temp_name = tmpnam(0)) != 0);
> !
> !   if (temp_name == 0)
>       return 0;
[snip]

DOS has a function that creates a temporary file, why cannot we use that
for tmpfile? We would at least never have a to cope with race conditions
:)

tmpfile is one aspect, the other functions that require a name to be
returned instead of a file descriptor (handle) still have to cope with
this kind of problems.
My idea is to provide a name for those functions based upon at least:
- a process ID (preferably r/m PSP address)   2^16
- the current time of the day in seconds      86400
- a counter (like it already has now)         X = large enough (like
800)

This resolution is enough to assert that:
- no same filenames are produced by different processes
- no same filenames are produced in one day
- no same filenames are produced by a single process during the same
second.
Conclusion: safe enough for us.

BTW to assure that X is large enough it may be necessary to decrease the
interval of the time if we want to stay within a 8 character filename
limit, unless we also want to use the extension as changeable part of
the filename.
Also BTW: if we include enough "weird" characters the previous "BTW" may
not apply.
i.e. Each position can contain 26 + 10 + n different characters, for
eight positions. When n is large enough (26 + 10 + n)^8 can be large
enough to have a sane value for X.
Question is: what other characters could we use as part of the filename?
f.i. '(' and '_' are quite safe, but other **valid** DOS filename
characters may yield problems like '[', '-' and '$'

Another problem, what should MAX_TEMPNAM (I'm not sure about this name,
but you should know what I mean) in one of the header files be like? The
value of X?

-- 
 \ Vik /-_-_-_-_-_-_/   
  \___/ Heyndrickx /          
   \ /-_-_-_-_-_-_/