Message-Id: <199904210513.FAA31728@out1.ibm.net> From: "Mark E." To: djgpp-workers AT delorie DOT com Date: Wed, 21 Apr 1999 01:13:43 -0400 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: A workaround for Unix-style temporary files X-mailer: Pegasus Mail for Win32 (v3.01d) Reply-To: djgpp-workers AT delorie DOT com Hi guys, Bash currently uses two similiar workarounds for not being able to handle Unix-style temporary files: fd = open ("foo.txt", O_RDONLY); unlink("foo.txt"); ... read from foo.txt ... close(fd); The above sample code is handles by adding the filename to a list. Then at a safe time, the files are deleted. A similiar workaround is used to handle deleting files leftover from emulating pipes. Wanting to have just one workaround, I created the _opentmp function. It accepts a path and mode as arguments and returns a file handle on success, a lot like open does. Except when close() is called, the file is closed and then automatically deleted. DJ or Eli, does this feature sound like something worth integrating into the next libc (the next libc with new features that is)? If so, it could be integrated into open() and used when say, O_TEMPORARY, is given in the mode. I would even be willing to write an Autoconf macro to detect the presence of _opentmp or O_TEMPORARY so GNU packages needing the workaround can be modified to "do the right thing". I might add that this feature was designed to have as little overhead as possible. 8 bytes total (256 handles / 8 bits per byte) are used to map which descriptors have files that should be removed on close, and the FILE struct is used to store the information needed to remove the file. And close() for non-temporary files only is slowed down long enough to check the bitmap. I can post the source if requested, or you can get it from the DJGPP part of my website. Mark --- Mark Elbrecht, snowball3 AT usa DOT net http://snowball.digitalspace.net/