How does GetFinalPathNameByHandle choose the name if there are multiple names due to hard links?


Alex Shalimov wonders how the Get­Final­Path­Name­By­Handle behaves in the face of hard links. If there are multiple equivalent names, which one is returned?

The function returns the name that was used to open the file.

Comments (13)
  1. JAHA says:

    I used to get new blogs at 1 pm pacific...now i get them 1pm eastern.

  2. The blog people tell me they are having database problems, so posts don't always show up. And I'm in Hawaii right now, so I don't wake up until several hours after scheduled posting time. You'll just have to deal with it.

    1. Brian_EE says:

      "This blog does not come with a Service Level Guarantee"

      1. Raymond could give an SLG for the blog, of course - and it'd be educational for people who see SLGs/SLAs/SLTs as more "important" than competent engineering[1].

        How about "20% refund on all money Raymond has charged you to access his blog"? No? You'd prefer 50%? I'm sure Raymond would go for that, too.

        [1] I've worked with one too many inexperienced managers who'd prefer the service with an SLA that keeps going down over the service backed by a competent team that doesn't go down very often, on the basis that an SLA is a good thing.

      2. JAHA says:

        It was just an FYI :)

  3. Ben Voigt says:

    If the particular link has been removed (may require use of NT API or the new Windows Services for Ubuntu Linux layer), does it still return the filename that was used to open the file, or will it change and return a different-but-still-valid filename if one exists?

    1. Joshua says:

      Excellent question. Normally the answer turns out to be you can't (because Win32 always takes a lock on the name); but if it's on a Samba share you certainly can.

      On a related note, I wonder how it would behave if the last name got removed.

      1. Kevin says:

        My psychic powers tell me this is an extreme edge case which nobody specifically bothered to handle, so we can answer the question by putting on our kernel-colored glasses. By far the easiest way to implement GetFinalPathNameByHandle is to keep track of the file name you used to open this particular handle in the first place. So I surmise that the kernel will simply return that value regardless of whether it's still valid.

    2. cheong00 says:

      I think the old name would still be returned to be consistant with Unix behavior. (In *nix, if file is deleted when in use by some process, the file will be invisible from outside but still "exist" in the view of process that using it. The nodes will only be freed after the last process holding handle to file closed it.)

      1. Neil says:

        Presumably this also applies to the case of renames.

  4. I wonder what happens if you got the handle using OpenFileById? (Probably you just get the first hardlink in whatever arbitrary order NTFS has them in.)

  5. Mihailik says:

    What if the handle is inherited?

    1. smf says:

      Why would it matter which process opened it?

Comments are closed.

Skip to main content