determining filename of unlinked open file

[Kevin Shortt]

Hello,

I am attempting to determine the full pathname of an unlinked open file. The file is detectable by lsof. I have used "lsof +aL1 /filesystem-name" to display information about my file.

Here is a sanitized version of my lsof output:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NLINK NODE NAME
processname 4380 root 197u REG 64,0x40001 255016960 0 2706 /filesystem-name (/dev/vg4/lvol01)


I would prefer to not re-invent the wheel. I am looking for the full pathname of the open file. I have begun to write a C program that will tell me all the information available about the open file with the fstat command. I have chosen the fstat because I have the file descriptor name available to me. (197)

Well, this is not working. I am receiving an errno of 9. (EBADF - Bad file number) This is telling me that I must not have access to it any longer since the controlling process must be the only one able to access the open file. I am puzzled that I am unable to get more information, when lsof was able to determine the existence of it, and report the FD number to me.

Does anyone have any insight for me?

my uname -a:

HP-UX hostname B.11.11 U 9000/800 4254029963 unlimited-user license

[Rodney Hills]

If this is an unlinked file, it has no path. Unlinked means that the directory tree does not have an entry pointing to the inode.

If it did, then you could do a-
find /filesystemname -inum 2706 -print

to find the path.

Rod Hills

[A. Clay Stephenson · Accepted solution]

By definition, an unlinked file (i.e. the link count has been reduced to zero) does not have a pathname associated with it so your question really has no meaning. The directory entry has already been removed and
the system is waiting for all processes which had the file open to either close() the file or terminate. When that condition is satisfied the space is actually freed within the filesystem.

So now your question is how does lsof display the file descriptor? Answer: lsof is kernel intrusive and has access to areas that normal system calls like fstat() do not. Moreover, file descriptors are not transportable across processes except in special cases (e.g parent/child). For example, file descriptor 6 in processA might be associated with "myfile" while file descriptor 6 in processB might be associated with "yourfile".

[Kevin Shortt]

Ahh..I see.

This is because the link between the directory and the inode is removed when the file is unlinked. (yes?)

So does that mean once the file has been unlinked there is no trace of actually where the file was created originally?


Thanks for your replies.

[A. Clay Stephenson]

Yes, you have the essence of it. Man 2 unlink explains the process quite well.

One of the standard UNIX idioms is something like this:

fdes = open("xxx/yyy/mytempfile",O_RDWR | O_CREAT,0600)
(void) unlink("xxx/yyy/mytempfile");
...
...
...
close(fdes);

The idea is that a file is created and opened and then immediately unlinked. This process (and perhaps its child processes) have complete access to this otherwise invisible file until all the processes close the fdes or terminate. This is essentially what the tmpfile() function does.

[Kevin Shortt]

Thanks to both responders. You have helped me understand unlinked files and sequence of events around them.

Thank you.