basic C question

[Taavi Burns]

On Mon, Jul 12, 2004 at 03:54:28PM -0400, fcsoft-3Emkkp+1Olsmp8TqCH86vg at public.gmane.org wrote:
> I've been struggling off and on with problems of this nature for a while.
> 
> Essentially the problem is how to detect that a file descriptor which was 
> previously successfully opened no longer points to a valid inode.

One would assume that the write call would return some kind of error,
though I'm not sure how an inode can 'disappear' like that.  (see below)

> 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().
> 
> Compile this code and run it.      It will write "go1" and "go2" into a file 
> called bob.dat separated by a sleep of 20 sec.
> 
> Repeat the test,  but after the first write go to another console and remove 
> the bob.dat file.  

So you've removed the reference to bob.dat from the current directory...

> The second write will still not return an error.    
> ie. file it is supposedly writing to is gone but the write() apparently quite 
> happily succeeds.

Of course it does.  Your program still has an active reference to the file
in question; the space has not been deallocated, nor has the inode been recycled.

> The question remains how can we verify the veracity of the file descriptor we 
> are about to write to before we actually allow the write to "succeed" 
> regardless.

As I said above, there's nothing wrong with this.  I've heard of this being done
for programs which want some limited modicum of security (the file still hits disk,
but at least you can't access it via filesystem calls after it's been unlinked,
and assuming that the fs' metadata is properly flushed after the unlink, the file
will still not appear if a hard crash is encountered).  Security by obscurity, yes.
But it is pretty obscure.  ;)

You might try the 'stat' syscall on the handle to determine how many references
the inode has, or stat where you think the file should be and compare inodes
(though this second method has the problem of incorreclty detecting a moved
file as a deleted file).

See "man 2 fstat".  I personally suspect that the st_nlink field will be 0 after
you unlink the file.

-- 
taa
/*eof*/
--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml