Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site uwai.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!uwvax!uwai!Thomas Scott Christiansen From: Thomas@uwai.UUCP Newsgroups: net.unix-wizards Subject: Re: How can unlinking be postponed? Message-ID: <234@uwai.UUCP> Date: Sun, 8-Sep-85 11:57:53 EDT Article-I.D.: uwai.234 Posted: Sun Sep 8 11:57:53 1985 Date-Received: Tue, 10-Sep-85 03:58:51 EDT References: <516@riccb.UUCP> Sender: tom@uwai.UUCP Distribution: net Organization: UWisc Systems Lab Lines: 29 First of all, one unlink()s *directory entries*, not inodes. If the inode pointed to by the directory entry has its link count decremented to zero, then that inode is deallocated *as soon as* the file is no longer open by anyone. As long as you have the file open, you can perform any operation on it you want that does not take a filename but rather just a descriptor, such as lseek, read, write, close, fchmod, etc., but not rename, access, or chmod. Once it is closed, it is gone. Thus the proper way to create a file which will be removed upon the process's exit is: invent a filename unlink the file (in case it already exists) create the file (saving the file descriptor) unlink the file Now only the creating process and its descendents (though inhereited file descriptors) may access the file, and the space will be reclaimed upon the process's exit. Note that if someone tried to create the file again while it was open but not in any directory, then a different file would be created! -- tom -- Tom Christiansen University of Wisconsin Computer Science Systems Lab ...!{allegra,heurikon,ihnp4,seismo,uwm-evax}!uwvax!tom tom@wisc-ai.arpa