Date: Mon, 9 Mar 1998 16:50:42 +0200 (IST) From: Eli Zaretskii To: Vik Heyndrickx cc: djgpp-workers AT delorie DOT com, Charles Sandmann Subject: Re: Temporary files considered unsafe In-Reply-To: <3503ECC0.571@rug.ac.be> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 9 Mar 1998, Vik Heyndrickx wrote: > > > What other program could want to open our file for writing? > > Another DJGPP program which calls `tmpfile' at the same time. > > Nope, DOS returns a different filename to the other prg. I'm quite sure > they got this right because it is essentially the reason why a function > like this exists within DOS. We should try it first to be sure. Anyway, I thought you are asking why did I add it in my version. > The chances this happens is extremely low AND also existant with YOUR > modified function. I don't see how. DENY_ALL means that no other program can open the file, come what may, right? So if one program created such a file, no other program could ever open it, period, no matter which method they use to open it. > Now that a really appropriate reason has been found to use the LFN->SFN > variety of that DOS function call, you don't like it :-( It's messy, since `_truename' might return something like "\\server\sys\foo\bar", and you need to convert it back to "d:\foo\bar" that DOS can grok. Why bother? > This all makes sense when both physical address spaces are different. > > Just to make very sure I understand it right, two DOS programs in a > different box cannot use the conventional memory area to pass data to > each other? No, they cannot, they use different page directories. Windows isolates two DOS apps much better than two Windows apps, even in Windows 9X. In fact, it even multi-tasks them better than two Windows apps. Which is a small wonder if you remember that Windows started as a DOS multitasker, and that part of Windows is being developed for a long time, something like since 1984, whereas the GUI thing is a much later add-on. > Can we get at our TSS somehow? I don't know. Charles, can you help here? (The context here is to generate a unique PID for a program, even when several DOS boxes run on the same machine at the same time.) > The value of getpid () somehow is not entirely distinct from the current > time, so it seems a bad candidate in the first place. It is good enough as long as you are on DOS, where only one program runs at any given time (so PID's of those which don't run don't matter). Windows breaks this. > It is NOT incorrect, since it defines only a lower bound. Question is > what is more appropriate. We could even set TMP_MAX as small as 25 > without breaking ANSI complianceness. I don't like this because 25 is too small. Somebody could make a loop that runs until TMP_MAX tries and then quits thinking that all of the possibilities had their chance and failed. Is that what you want? If so, then 25 is the right number.