Date: Mon, 9 Mar 1998 14:42:29 +0200 (IST) From: Eli Zaretskii To: Vik Heyndrickx cc: djgpp-workers AT delorie DOT com Subject: Re: Temporary files considered unsafe In-Reply-To: <3503D9F5.1D0E@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: > > It's another safeguard, that's all. > > What other program could want to open our file for writing? Another DJGPP program which calls `tmpfile' at the same time. E.g., two compilations running in two different DOS boxes, or on two different machines with the same shared temporary directory. One of the two programs could be linked with an old version of the library which doesn't care if the file already exists. > The same I was referring to above, you pass a path and DOS appends the > filename for the newly created temp-file. Yes, but the problem is that there is no LFN cousin of that function, so you cannot create files in directories with long names (and I didn't want to enter the `_truename' mess to resolve this). Oh, btw, I just looked closer at the latest release of the Interrupt List, and it clearly says that 215A opens the file in compatibility mode. > I don't understand "mapped into all DOS boxes" vs. "kept separate". > Either any DOS program has a different "below 640Kb + UMB" address > space, or it has the same. > You imply the first? There are physical addresses, and there are logical addresses. The first 1MB of every DOS box has the same logical addresses, but different physical addresses. When Windows task-switches, it changes the page directory so that the same logical address (e.g., the DOS PSP of the running program) now points to a physically different address. So the same PSP of COMMAND.COM now points to a different copy of COMMAND.COM in each DOS box. > PSP-segment IS unique? No, they are definitely not unique. You can run a simple program that calls the DOS GetPSP function in several DOS boxes and see for yourself. Assuming that all DOS boxes are configured the same (i.e., you load the same, if any, TSRs and device drivers, etc.), it will display exactly the same PSP. > > DJGPP's `getpid' doesn't use the PSP address. It reads the BIOS clock > > tick count the first time it is invoked in the given program, then caches > > the value and returns it hence. > > Then it most certainly not suits what I want as a unique value, since > two programs can be started in the same 1/18.2s period. It's better than once per second as you suggested. And if you have a better way of getting a unique PID, please tell, as this issue (of unique PID) bothers me a lot, with the proliferation of fast machines. > X was the counter value (equivalent to the current counter in > tempnam[e]). This value should prevent from different names to be > generated during the same second by one program. > > Because a program cannot create more than X values during the same > second I feel like setting MAX_TEMPNAM = X, but the program potentially > can create 86400 * X in one day. That is why I am so careful about not > setting it to 24 * 60 * 60 * X. `tmpnam' is an ANSI function, and ANSI Standard rules as follows: "The `tmpnam' function generates a different string each time it is called, up to TMP_MAX times. If it is called more than TMP_MAX times, the behavior is implementation-defined." So it seems incorrect to set it to X, as nobody says that all TMP_MAX calls are done in a tight loop. I read the above as a promise to have at least TMP_MAX different names that can be produced. (And in case you wonder what does this have to do with `tmpfile': AFAIK, Posix specifically says that `tmpfile' calls `tmpnam'. At least most Unix systems behave that way.) > > And how do you account for the truncation to 8+3 namespace? > > I simply create filenames that ARE 8+3 (and don't contain '~' BTW), I > don't know why I should make things more complicated? No, I meant to ask how do you compensate TMP_MAX, since X*86400 is more than you can squeeze into a 8+3, no?