basic C question

[fcsoft-3Emkkp+1Olsmp8TqCH86vg at public.gmane.org]

OK but my real problem is not with a file but rather a named pipe or fifo.    
The file example was my attempt to "simplify" my real problem.

Once again if process A (the reader) creates the named pipe and process B 
(the writer) opens a file descriptor to that pipe there appears to be no way 
to detect that process A (the reader) has vanished.    ie. the write() will 
always succeed.

Nuts.

Interestingly there is an EPIPE error on a write() which is supposed to come 
up for exactly this condition but it never does.

Presumably the kernel maintains info about exactly how many processes have 
open file descriptors.     

Is there any way to use that to detect this condition?    or am I going to 
have to go with some brain dead access(blah, F_OK) solution ... yuk?

Thanks for all your answers so far.

On July 12, 2004 04:13 pm, you wrote:
> 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.
> >
> > 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.      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.
> >
> > 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.
> >
> > Any help appreciated.
>
> The file is not actually removed until all handles to it are closed.
> The entry is removed from the directory so there is no way anyone else
> can open that inode, but your program keeps access to that inode until
> it closes the file.
>
> If you want to check if the file you have open has been deleted, you
> probably have to check the directory contents, or open the file a second
> time.  You could always close and reopen the file between writes (open
> in no create mode to no make a new file).
>
> Lennart Sorensen
--
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