www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1999/04/21/10:54:47

From: Alain Magloire <alainm AT rcsm DOT ece DOT mcgill DOT ca>
Message-Id: <199904211454.KAA26575@mccoy2.ECE.McGill.CA>
Subject: Re: A workaround for Unix-style temporary files
To: djgpp-workers AT delorie DOT com
Date: Wed, 21 Apr 1999 10:54:28 -0400 (EDT)
In-Reply-To: <199904210513.FAA31728@out1.ibm.net> from "Mark E." at Apr 21, 99 01:13:43 am
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Reply-To: djgpp-workers AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

Bonjour 

> 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.

Technically the unlink() is correct, file removal with unlink() is well
defined within POSIX definition :

From Posix.1 p127
int unlink(const char *path) :
	The unlink() function shall remove the link named by the pathname
	pointed to by path and decrement the link count of the file
	referenced by the link.
	When the link count of the file becomes zero and no process has the
	file  open, the space occupied by the file shall be freed and the file
	shall no longer be accessible.  If one or more processes have the
	file open when the last link is removed, the link shall be removed
	before unlinks returns, but the removal of the file contents shall
	be postponed until all references to the file been closed.
	The path argument shall not name a directory ......
------------------------------------

NT is claiming to be POSIX compliant, they should get this right.
I don't know about Win9x and the DOS variants.  

And there is remove() define by STD C :
int remove(const char *filename);  
	The function removes the file with the filename filename and
	returns zero if successful. If the file is open when you remove it,
	the result is implementation defined. After you remove it, you
	cannot open it as an existing file. 

> 
> 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.

What makes it so attractive on Un*x and other POSIX syst. is that the behaviour
will be consistent even when the program crash.  You could use atexit()
to cleanup, but when the program die unexpectedly its hard to cleanup
without coorporation of the OS.


-- 
au revoir, alain
----
Aussi haut que l'on soit assis, on est toujours assis que sur son cul !!!

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019