2019年9月15日(日) 9:06 Christos Zoulas <chris...@astron.com>: > In article <2f29ca9a-0ae1-48d3-b3f4-1556912d4...@me.com>, > Jason Thorpe <thor...@me.com> wrote: > > > > > >> On Sep 14, 2019, at 2:52 PM, Kamil Rytarowski <n...@gmx.com> wrote: > >> > >> On 14.09.2019 23:34, Christos Zoulas wrote: > >>> Comments? > >>> > >> > >> Question. How does it handle symbolic/hardlinks? > > > >Symbolic links, of course, are simply continuations of the lookup, so > >there's "nothing to see here" with a symbolic link. > > If you can get a file desriptor to a symlink, it will work; I don't think > that we have a way to do this now. > > >I looked at cache_revlookup() and it looks to me like it simply picks > >the first hit it finds in the hash table for the given vnode. > > That is correct. > > >At least one platform that support this API uses "the last name the file > >was looked up with", and will fall back on "whatever the underlying file > >system considers to be the canonical name for the file", which is file > >system-defined, if for some reason there is no entry in the name cache > >(which could, for example, happen if an application is doing an > >"open-by-file-id" type operation and the file has not yet been opened by > >path name). > > It will also fail if the entry has been evicted from the cache, but that > rarely happens with recently opened files. >
if we want to provide this API, it should be done in a reliable way. "rarely fails" is not reliable enough, IMO. > > christos > >
