[PATCH] D155579: [Windows] Avoid using FileIndex for unique IDs on network mounts

Martin Storsjö via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Aug 22 06:09:40 PDT 2023


mstorsjo added a comment.

In D155579#4606508 <https://reviews.llvm.org/D155579#4606508>, @mstorsjo wrote:

> In D155579#4606503 <https://reviews.llvm.org/D155579#4606503>, @aaron.ballman wrote:
>
>> In D155579#4604541 <https://reviews.llvm.org/D155579#4604541>, @mstorsjo wrote:
>>
>>> You who might have more use of nontrivial Windows build scenarios - how much impact would it be to go all in on the new path canonicalization + hash approach, i.e. ditching the file index entirely? Performance wise I would believe that it would be no significant change to before. The only thing that matters probably is how it behaves wrt symlinks/hardlinks, if those are present and in use.
>>
>> A related question for hashes -- what about case insensitivity of file paths and slash direction? Presumably we want `F:\foo\Bar` to be the same path as `F:/FOO/BAR`?
>
> Yes, that's something that certainly would come up a lot. The approach taken by this patch is that we run all paths through `realPathFromHandle`, which calls `GetFinalPathNameByHandleW`, https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getfinalpathnamebyhandlew, which should return a canonicalized path name for this file.

I guess the follow-up then is that we should check how `GetFinalPathNameByHandleW` behaves wrt potential symlinks and hardlinks - if it canonicalizes them as we'd like, then I guess it should be quite safe to always go with the hashing.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D155579/new/

https://reviews.llvm.org/D155579



More information about the llvm-commits mailing list