Skip to content

[Support] Use the file id for UniqueID on local NTFS and ReFS volumes - #232

Draft
tagolog wants to merge 1 commit into
swift/stable/23.xfrom
tagolog/windows-status-fileid
Draft

tagolog wants to merge 1 commit into
swift/stable/23.xfrom
tagolog/windows-status-fileid

Conversation

@tagolog

@tagolog tagolog commented Nov 13, 2026

Copy link
Copy Markdown

getStatus() builds UniqueID from a hash of the NT path returned by GetFinalPathNameByHandleW, because file indices are not stable on every file system (ImDisk, network redirectors; see rust-lang/rust#86447). The call is expensive: on NTFS it is about half of sys::fs::status, and the dependency scanner pays it twice for every file it sees for the first time, once for the status by path and once for the status of the opened file.

On a local fixed NTFS or ReFS volume that supports opening by file id, the 128-bit id from FILE_ID_INFO identifies a file for as long as it exists. Hash that id there and keep the path hash on all other volumes. Whether a volume qualifies is decided once per volume serial number and cached.

With Follow, status(path) first tries GetFileInformationByName (Windows 11 24H2 and later, looked up at run time), which returns the same data without opening a handle. Reparse points, non-disk devices, volumes not yet known to have stable ids and errors other than "not found" take the existing handle path.

getStatus() builds UniqueID from a hash of the NT path returned by
GetFinalPathNameByHandleW, because file indices are not stable on
every file system (ImDisk, network redirectors; see
rust-lang/rust#86447). The call is expensive: on NTFS it is about half
of sys::fs::status, and the dependency scanner pays it twice for every
file it sees for the first time, once for the status by path and once
for the status of the opened file.

On a local fixed NTFS or ReFS volume that supports opening by file id,
the 128-bit id from FILE_ID_INFO identifies a file for as long as it
exists. Hash that id there and keep the path hash on all other
volumes. Whether a volume qualifies is decided once per volume serial
number and cached.

With Follow, status(path) first tries GetFileInformationByName
(Windows 11 24H2 and later, looked up at run time), which returns the
same data without opening a handle. Reparse points, non-disk devices,
volumes not yet known to have stable ids and errors other than "not
found" take the existing handle path.
@github-actions

Copy link
Copy Markdown

Hello @tagolog 👋

Thank you for submitting a Pull Request (PR) to the LLVM Project. Since this is your first PR, here are a few useful links covering our main contribution policies and review practices.

  • All contributions to LLVM must follow our LLVM AI Tool Use Policy. In particular, if you used AI while working on this PR, remember to add a note to the PR description.
  • The LLVM Code-Review Policy and Practices document contains practical information about the PR process, including how patches are reviewed and accepted, and who can review a PR.
  • Our LLVM Developer Policy describes our expectations for code quality, commit summaries and contains notes on our CI system.

Please reply to this message to confirm that you have read these policies, especially the LLVM AI Tool Use Policy, and that any AI tool usage has been noted in the PR description.


Frequently asked questions

How do I add reviewers?

This PR will be automatically labeled, and the relevant teams will be notified. For some parts of the project, reviewers may also be added automatically.

You can also add reviewers manually using the Reviewers section on this page. If you cannot use that section, it is probably because you do not have write permissions for the repository. In that case, you can request a review by tagging reviewers in a comment using @ followed by their GitHub username.

What if there are no comments?

If you have not received any comments on your PR after a week, you can request a review by pinging the PR with a comment such as “Ping”. The common courtesy ping rate is once a week. Please remember that you are asking for volunteer time from other developers.

Are any special GitHub settings required to contribute to LLVM?

We only require contributors to have a public email address associated with their GitHub commits, see this section of LLVM Developer Policy for details.


If you have questions, feel free to leave a comment on this PR, or ask on LLVM Discord or LLVM Discourse.

Thank you,
The LLVM Community

@tagolog
tagolog requested a review from slydiman November 13, 2026 05:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant