Jerome, Thanks 

I had not thought of the unlink before close.  

For my requirements, I did think of piping the output from the program that 
creates the file to the program that reads it.  But this solution may not 
work.  

Cheers and thanks again. 

------------------

Regards  
 Leslie
 Mr. Leslie Satenstein

 
mailto:[email protected]
mailto [email protected]
www.itbms.biz
 

--- On Tue, 7/20/10, Jérôme Oufella <[email protected]> wrote:

From: Jérôme Oufella <[email protected]>
Subject: Re: [MLUG] Is there a file close command that is an atom command?
To: "Montreal Linux Users Group" <[email protected]>
Date: Tuesday, July 20, 2010, 1:07 PM

----- "Peter" <[email protected]> a écrit :

> do the unlink before the close or immediately after open. Your process
> keeps the file handle, can read/write, seek etc... but no-one else can
> open it. On close, the file will disappear as the last link to it will
> be removed it will land on the free block list.
> 
> 
Note that it will not warrant you that the file remains unused by others:
A concurrent process could still create a link to your file before unlink()
occurs (ie. using an inotify watch).
You might want to combine that to various permissions tricks,
depending on your robustness requirements. Have a look at mkstemp(3).


Jerome Oufella


> 
> On Mon, Jul 19, 2010 at 9:39 PM, Leslie S Satenstein <
> [email protected] > wrote:
> 
> 
> Background
> 
> When I was an IBMer, and using the VM machine, back in 1970, we had a
> file type that was called scratch, or temp.
> This file type had the property that one could open it, write, rewind,
> or even seek to a position. But the one quality it had was that on a
> close, the file was purged. That is, the close of this file did a
> unlink without having to first do a fclose() followed by the unlink().
> 
> Now the question
> 
> What if any similar function is available in Linux? How can I insure
> that the fclose() immediately followed by the unlink(), on the same
> hardware system, is not interruptable?
> 
> Oh yes, as I remember, one could not share a temp file. These temp
> files were often used for sort-work areas or compiler work-areas.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ------------------
> 
> 
> 
> Regards
> 
> Leslie
> 
> Mr. Leslie Satenstein
> 
> 
> mailto:[email protected]
> mailto [email protected]
> www.itbms.biz
> 
> _______________________________________________
> mlug mailing list
> [email protected]
> https://listes.koumbit.net/cgi-bin/mailman/listinfo/mlug-listserv.mlug.ca
> 
> 
> 
> _______________________________________________
> mlug mailing list
> [email protected]
> https://listes.koumbit.net/cgi-bin/mailman/listinfo/mlug-listserv.mlug.ca
_______________________________________________
mlug mailing list
[email protected]
https://listes.koumbit.net/cgi-bin/mailman/listinfo/mlug-listserv.mlug.ca
_______________________________________________
mlug mailing list
[email protected]
https://listes.koumbit.net/cgi-bin/mailman/listinfo/mlug-listserv.mlug.ca

Reply via email to