hutchson@convex.UUCP (03/10/88)
GCOS has a similar bifurcation between (global) file names and (local) file
descriptors. The "file descriptors" are set up by the environment--the usual
jcl or shell commands.
We (I was supporting GCOS Fortran-77 at the time) had endless complaints
from users about what was possible/difficult/confusing about file access via
the OPEN statement, until we adopted a scheme essentially identical to the one
suggested:
1) open status='scratch' generated (or accessed) a temporary file in the
local name space: it usually vanished at job close but could be left
around via close status='keep' (This last, of course, is an extention
to the ANSI standard.
2) open name='ambiguous name' looked first in the local name space then
in the global name space for the file; if not found, it created it in
the global name space.
3) open name='global name' (The local name space was a subset of the
global name space) looked in the global name space; if not found, it
created it.
This made everyone happy: it is general enough that plain-vanilla use of
open works as on other systems, powerful enough to do anything you could
think of doing with an OPEN statement, easy to explain.
I work on unix now, and I miss temporary files. Yes, I know about mktemp:
it doesn't work at all well, and I wrote a better one for my own uses. But
there is no such thing on unix as a temporary file that steals SWIFTLY and
silently away as soon as the job finishes executing. This is not a feature;
this is a severe limitation! It is not possible to simulate temporary files
on unix without great effort; it is a pain even to pretend to simulate it.
"And there was evening and morning, another day. And abortive processes
generated four more files in /tmp, and the system manager saw that it was not
good, for verily the partition overflowed and the system rested on the seventh
day."levy@ttrdc.UUCP (Daniel R. Levy) (03/12/88)
In article <68000011@convex>, hutchson@convex.UUCP writes: > I work on unix now, and I miss temporary files. Yes, I know about mktemp: > it doesn't work at all well, and I wrote a better one for my own uses. But > there is no such thing on unix as a temporary file that steals SWIFTLY and > silently away as soon as the job finishes executing. This is not a feature; > this is a severe limitation! It is not possible to simulate temporary files ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > on unix without great effort; it is a pain even to pretend to simulate it. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I'd challenge that. Files which are open when they are unlinked stick around until the process that opened them terminates. What's so hard about: char *tmpfnam = mktemp("/tmp/XXXXXX"); int fd = creat(tmpfnam,MODE); unlink (tmpfnam); /* You can still scribble in the temp file, * and read it, via the file descriptor. * It goes away when the process terminates. */ or in f77 character*16 tmpnam open (unit=1,status='scratch') inquire (unit=1, name=tmpnam) open (unit=2,file=tmpnam,status='old') close (unit=2, status='delete') C or for the two lines immediately above, substitute C C call system('rm -f '//tmpnam) C C now you can access your scratch file through logical unit 1 C and even if the program dies abnormally, the scratch file goes C away -- |------------Dan Levy------------| Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, | an Engihacker @ | <most AT&T machines>}!ttrdc!ttrda!levy | AT&T Computer Systems Division | Disclaimer? Huh? What disclaimer??? |--------Skokie, Illinois--------|
aglew@ccvaxa.UUCP (03/13/88)
..> UNIX not having temporary files
..> versus the open/unlink trick that keeps your file open until
..> your process dies.
I'm of two minds about scratch files. On the one hand, I like not
having to explicitly, or externally, clean up; on the other hand,
I sometimes used to wish that I could look at a scratch file after
a program aborted ("Hey Mr. POD, my program aborted after 2 hours!"
"Well, how far did it get?" "Oh, all the temporary results are stored
in a scratch file...")
A good checkpoint facility obviates this need.jlg@a.UUCP (Jim Giles) (03/15/88)
> UNIX not having temporary files > versus the open/unlink trick that keeps your file open until > your process dies. This won't work on most UNIX systems if you want to be able to conduct an adequate post-mortem on a job that dies prematurely. The contents of a scratch file may be vital in determining the problem. Since UNIX doesn't contain a restart capability for aborted jobs, this problem is not as great as it might be (but the lack of a post-mortem restart facility severly impairs the UNIX environment). Since the standard doesn't specify what should happen when a job terminates abnormally, I recommend that the I/O library should not destroy scratch files until a NORMAL termination. This leaves a method to debug code corpses. J. Giles Los Alamos