basic C question

John Macdonald john-Z7w/En0MP3xWk0Htik3J/w at
Mon Jul 12 20:53:57 UTC 2004

On Mon, Jul 12, 2004 at 04:03:35PM -0400, G. Matthew Rice wrote:
> fcsoft-3Emkkp+1Olsmp8TqCH86vg at writes:
> > Essentially the problem is how to detect that a file descriptor which was 
> > previously successfully opened no longer points to a valid inode.
> > 
> > Here is some code which uses a standard file which illustrates quite simply  
> > that write() will not fail when the inode is removed after a successful 
> > open().
> That is a feature of Unix, actually.  The file still exists and takes up disk
> space until all file descriptors to a file are closed.
> Some options for you are:
> 1. use fstat(2) with the file descriptor and see if the returned structure
>    notices that the inode is gone.  I haven't tested this.  I don't know if
>    it'll work.
> 2. try and reopen the file once in a while to see if it has been deleted or
>    renamed.

Of course, even if you do verify that the inode is still
referenced by the original directory entry, you have no
way to ensure that it will remain so.

There will be 3 different events:

1. your program tests that the file is "really still there"

2. your program writes the data

3. your program or some other program tries to read the data back

While you can detect whether some outside agency removed
the original file as event 1, that provides no assurance
that the outside agency is running a bit slow today and
doesn't get around to deleting the file until a bit later,
either before event 2 or 3 (or even later, which you
probably wouldn't mind).

If keeping the file around until event 3 is important, you
have to use other means to ensure it.  That can require
having your C program run with ts own account and use
the permissions system to prevent any outside agency from
removing the file; or, if it is a part of the same program
suite that must also remove the file, then use locking to
prevent removal when the file is still is use.

The Toronto Linux Users Group.      Meetings:
TLUG requests: Linux topics, No HTML, wrap text below 80 columns

More information about the Legacy mailing list