This kind of race condition points to bugs in the file system code
namely link counts and lack of proper locks.  To change the semantics of
/tmp in order to fix this is going to make tons of scripts break,
confuse users and provide nothing but a hack fix at best.

Is there a reasonably accurate list of bugs surrounding /tmp?  If so,
how many can be classified as "race" conditions and probably be fixed
directly in the file system?

bill

>----------
>From: 	Perry E. Metzger[SMTP:perry@piermont.com]
>Sent: 	Monday, February 24, 1997 7:34 AM
>To: 	David Brownlee
>Cc: 	tech-kern@NetBSD.ORG; tech-security@NetBSD.ORG
>Subject: 	Re: Per-user temp storage 
>
>
>David Brownlee writes:
>> On Mon, 24 Feb 1997, Frank van der Linden wrote:
>> 
>> > I don't think modifying a filesystem in this way is a good idea at all;
>> > it's something that should not be in the kernel. As soon as you start
>> > plugging holes by modifying the kernel, while there is a good userspace
>> > solution possible (i.e. mkstemp(3)), then you're on the wrong track.
>> > 
>> 	It would help if at least source in the tree used mkstemp() rather
>> 	than mktemp(), tmpnam(), tempnam(). 
>> 
>> 	Maybe add a warning for the above functions in a similar fashion
>> 	to 'gets()' - I believe OpenBSD did something like that a while
>> 	back.
>
>This is certainly useful, but it doesn't solve the "play with symlinks
>and deep directories during nightly find" problem.
>
>Perry
>