/tmp versus temporary file types

[BostonU SysMgr]

>From: peter at graffiti.UUCP (Peter da Silva)
>> 
>> Just a design note: On our IBM system files are named on CLOSE rather
>> than open...
>> ...
>> besides tmp files it just generally guarantees that programs which
>> for some reason, um, er, abend, and don't want things left around
>> can have that...

>But the usual case where you *do* want to keep the file around dies
>horribly if you do this...

Re-read the note, by my suggestion you would only get an unnamed file which
disappears on abend if you explicitly called open(NULL,mode);, or something
like that (the design problem with that is which device to put the unnamed
file on tho I guess something could be done like it always is on /tmp
wherever that is.) In the case you mention of the shell redirection one
assumes it is not being called with NULL so it has no effect on that. There
is a slight problem still if you were debugging, say, the C compiler and
really wanted to abort it leaving the temps around, tho there are obviously
better ways to accomplish the same effect.

--While we are on the subject, a quick opinion--

There have been notes in this list suggesting new features to UNIX,
typically at the system call level.
There have been notes in this list rejecting new features either
specifically or in general.

The notes which reject them in general are fairly useless I believe,
unless you consider UNIX to be completely finished.

The notes which reject things in specific are valuable, that is discussion.
(like Peter's note above, I just think he misunderstood my suggestion,
probably my fault.)

A paradox of UNIX has been to maintain great portability/compatibility with
itself over time while adapting to changing needs. Would the person who
screamed about features remove, say, TCP/IP from 4.2? I doubt it, except
as a wholly selfish exercise. On the other hand, being very suspicious of
any new proposed feature is quite a reasonable attitude in my opinion,
but the specifics should be dealt with to have useful discussion.

As far as it relates to this /tmp business, we are discussing a security and
integrity problem (I started this discussion) which is very visible,
obviously we have lived this long w/o a solution, but I suspect we have paid
intermittently with problems for administrators. It is also a very realistic
criticism when, for example, choosing UNIX for a student environment
(*my* real world, which probably involves more $$ and people than many who
claim some monopoly on what the *real* world is -- side flame, sorry.)

We can live w/o this solution, maybe there just is no good solution in
general, but we can't live with an attitude that nothing should ever change
as some have proposed to this list. That would be suicide.

	-Barry Shein, Boston University