Re: Keep a fifo's name until the close of its last connected fd



code17@xxxxxxxxx wrote:
By "man 2 unlink", I get "... If the name was the last link to a file
but any processes still have the file open the file will remain in
existence until the last file descriptor referring to it is closed".

I like this behavior because the both points following are desirable
in my case:

- If there is still one fd connected to the file, the next fd
trying to open the name will connect to that exact file

No. If unlink() has been called on a file it can't be accessed
by its name anymore since the name doesn't exist anymore, just
the file without a name - only processes that had it opened be-
fore the unlink() can still access it (they don't need the file
to have a name in the file system since they have its file des-
criptor). If a process opens a file with the name of the unlinked
file a new file by that name gets created which is completely un-
related to the file that had this name previously.

- meanwhile, if no fd connecte to the file, the name is automatically
garbage collected.

"Garbage collected"? The name vanishes the moment unlink() is
called, but the (then unnamed) file only vanishes when the last
process having it open closes it.

However, this doesn't work for fifo, as the manual states "... If the
name referred to a socket, fifo or device the name for it is removed
but processes which have the object open may continue to use it...".

That's exactly the same as for a "normal" file. I guess this isn't
meant to indicate a difference to the behavior of normal files but
instead is supposed to point out that the behavior is identical
for things not being "normal" files.

In that case, when I unlink a name, the lastely opened fd will
actually connected to a new fifo (with O_CREAT), even if there are
still fd waiting on the old fifo for reading/writing.

If you mean with "lastely opened fd" the result of a call of
open() after the unlink() call then this is correct, indepen-
dent of what it is, file, fifo, socket (or device file).

Image we have a bunch of independent processes, communicate thourgh a
named pipe (fifo) now and then, but we don't know who is (and when)
the last process to exist, so we have no way to ask the last process
to garbage collect the name. If the unlink behavior on normal file
acts the same on fifo, then we can ensure that

The last process opening the file/fifo/socket has to unlink it
(probably best directly after the successful open() call). The
(then unnamed) file/fifo/socket will continue to exist until
the last process having it open (which isn't necessarily the
last process to open it) closes it.

Regards, Jens
--
\ Jens Thoms Toerring ___ jt@xxxxxxxxxxx
\__________________________ http://toerring.de
.



Relevant Pages

  • Re: [linux-cifs-client] Re: unlink behavior when file is open by other process
    ... Both open and unlink man pages list plausible return codes but I ... opens file ... So this will work against a server that doesn't support rename by ... The create will fail. ...
    (Linux-Kernel)
  • Re: using wc -l in perl
    ... It opens the log file once at the start; ... unlink "$parent_path/$file" or warn "Cannot unlink ...
    (perl.beginners)
  • Re: using wc -l in perl
    ... John W. Krahn wrote: ... It opens the log file once at the start; ... unlink "$parent_path/$file" or warn "Cannot unlink ...
    (perl.beginners)
  • Re: Keep a fifos name until the close of its last connected fd
    ... # existence until the last file descriptor referring to it is closed". ... An unlink should immediately remove the link from the path to ... an ENOENT or the path will point to a different resource. ... The resource itself will persist until all opens are closed. ...
    (comp.unix.programmer)
  • race condition?
    ... logit(LOG_DEBUG, "put debug msg here"); ... logfile then creates a FIFO and opens it for reading. ... logit(int priority, const char *msg) ...
    (comp.unix.programmer)