Sender: vheyndri AT rug DOT ac DOT be
Message-Id: <3503C317.3A36@rug.ac.be>
Date: Mon, 09 Mar 1998 11:23:19 +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: djgpp-workers AT delorie DOT com
Subject: Re: Temporary files considered unsafe
References: <Pine DOT SUN DOT 3 DOT 91 DOT 980309114609 DOT 22925S-100000 AT is>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

Eli Zaretskii wrote:
> 
> On Mon, 9 Mar 1998, Vik Heyndrickx wrote:
> 
> > DOS has a function that creates a temporary file, why cannot we use that
> > for tmpfile?
> 
> Because it is not flexible enough: you cannot open the temporary file
> with DENY_ALL sharing property

You are right that you cannot get full access control, but is that
necessary?
In which sharing mode would such a file be opened by default? The most
sensible mode precisely seems DENY_ALL, but I'll need to test that. The
importance for being able to open a file in a particular sharing mode
seems low.

>                                , and you cannot control the name DOS
> creates (it's not needed for `tmpfile', but *is* needed for `mkstemp')

But not for tmpfile :-)

> and the place where DOS puts it (we want it to go to $TMPDIR, for
> example).

IIRC this can be controlled through the DOS call.
 
> > 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.
> 
> This problem always exists, AFAIK you can't do anything about it unless
> you actually open the file when you create the name (and leak file
> handles).

The problem will indeed always exist, but the chances that a name
collision occurs with our current implementation is almost 100% when you
have two processes running long enough at the same time. The method I
describe decrease this chance to nearly 0%
Since it is impossible to solve the problem perfectly, it seems a
valuable alternative.

> > My idea is to provide a name for those functions based upon at least:
> > - a process ID (preferably r/m PSP address)   2^16
> 
> Won't all first-level programs in different DOS boxes on Windows have the
> same PSP address?

I though the DOS conventional memory was common to all DOS boxes, or am
I so wrong?
If you are right, what about getpid()?

> > This resolution is enough to assert that:
> > - no same filenames are produced by different processes
> 
> Not if the PSP problem above exists.  You would need the VM id to cover
> for this.
> 
> > - no same filenames are produced in one day
> 
> What would stop two programs to start on the same second in two different
> DOS boxes?  E.g., imagine two Make's running in two different DOS boxes:
> they can easily launch GCC with less than 1 sec between them (on a fast
> machine).

This remark belongs to the point above, with a different PID this could
not occur.
BTW, The filename creation function would still check whether the
filename belongs to an existing file before returning it to the user.

> > 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?
> 
> AFAIK, this is the max number of unique names we can *potentially*
> generate.

Meaning, in the example above 86400 * X ?

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