fstat and filenames

[Robert Watson]

On Fri, 21 Dec 2007, Denis Eremenko wrote:

> ? ??, 14/12/2007 ? 09:03 -0500, Lowell Gilbert ?????:
>> moonshade at pnhz.kz (Denis Eremenko) writes:
>>
>>> Why fstat so secretive about file names and unix domain sockets?
>>
>> With respect to file names, you need to remember that there may not be a 
>> unique answer.  A file handle's metadata doesn't keep information about how 
>> it was opened, just the inode.  That inode could belong to multiple 
>> directory entries, or none -- this is why, as the fstat(1) manual points 
>> out, "there is no mapping from an open file back to the directory entry 
>> that was used to open that file."
>
> Yes. I clearly understand difficulties of exact inode-name mapping. And i 
> saw manpage note too. But doesn't _some_and_maybe_wrong_ information better 
> than nothing? Additionally - most files has one filesystem record.
>
>> As far as unix domain sockets, I don't understand the question.  Sorry.
> fstat doesn't show their names too.

The procstat(1) command now present in 8.x, and likely to be MFC'd to 7.x 
after 7.0 but before 7.1 will allow you to inspect that information.  And 
indeed, it will sometimes fail to be able to resolve a path for the object in 
which case it won't return one.  It needs a bit of refinement before it can be 
MFC'd; it relies on the kernel vn_fullpath(9) KPI, which uses the name cache, 
but some synthetic file systems (i.e., devfs) don't use the name cache, so it 
fails for all device nodes (for example).

Robert N M Watson
Computer Laboratory
University of Cambridge