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

[Martin Storsjö via Phabricator via llvm-commits]

mstorsjo updated this revision to Diff 555711.
mstorsjo added a comment.

Changed to always use a hashed path instead of nFileIndexHigh/nFileIndexLow, without any heuristics for when to do this. With this, I'm measuring a slowdown of around 1% in the test with clang-scan-deps.

How does this behave in your testcase @aganea?

I applied the suggestion regarding wonky file system drivers from Rust, and using VOLUME_NAME_NT, which works with such drivers too (tested with ImDisk, and confirmed that the default VOLUME_NAME_DOS fails there). We don't need to do fallbacking/testing between different formats here as we're not interested in the actual contents of the canonicalized path (we're not using it for anything), we're just interested in its identity.

For the potential case if GetFinalPathNameByHandleW still fails with VOLUME_NAME_NT, fall back on the old behaviour of using nFileIndexHigh/nFileIndexLow.

The only known drawback in this case is that we won't be able to notice two names pointing at the same hardlinked file - but I would believe that to be a compromise that we can affort to do on Windows (where hardlinks generally are rare).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D155579

Files:
  llvm/include/llvm/Support/FileSystem.h
  llvm/lib/Support/Windows/Path.inc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D155579.555711.patch
Type: text/x-patch
Size: 5642 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20230904/6e73f5b4/attachment.bin>