<table border="1" cellspacing="0" cellpadding="8">
    <tr>
        <th>Issue</th>
        <td>
            <a href=https://github.com/llvm/llvm-project/issues/61401>61401</a>
        </td>
    </tr>

    <tr>
        <th>Summary</th>
        <td>
            [Windows] File IDs aren't properly unique in some file share mounts
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            platform:windows
      </td>
    </tr>

    <tr>
      <th>Assignees</th>
      <td>
      </td>
    </tr>

    <tr>
      <th>Reporter</th>
      <td>
          mstorsjo
      </td>
    </tr>
</table>

<pre>
    CC @tru @aganea @zmodem @nico and others who might know something about Windows.

In https://github.com/mstorsjo/llvm-mingw/issues/327 I got a report of various intermittent random failures with using a LLVM based toolchain. After some digging, we found out that the issues are related to using file share mounts.

Observations:
- Folders shared from the user host with MS Remote Desktop (tested from macOS) show the issue
- Folders shared from the host system with VirtualBox allegedly also show the issue (as reported by the original poster)
- Folders shared from the host system with VMWare Fusion don't show the problem
- Folders mounted from a Samba server don't show the problem

The problem appears in different forms, depending on whether the source files or the toolchain itself (or both) are located on the file share. The problems are nondeterministic.

In the case of linking, the symptom is that lld fails to resolve a lot of symbols, e.g. like this:
```
ld.lld: error: undefined symbol: __set_app_type
>>> referenced by ../crt/crtexe.c:0
>>> z:/llvm-mingw-x86_64/x86_64-w64-mingw32/lib/crt2.o:(pre_c_init)

ld.lld: error: undefined symbol: __p__fmode
>>> referenced by ../crt/crtexe.c:119
>>> z:/llvm-mingw-x86_64/x86_64-w64-mingw32/lib/crt2.o:(pre_c_init)

ld.lld: error: undefined symbol: __p__commode
>>> referenced by ../crt/crtexe.c:120
>>> z:/llvm-mingw-x86_64/x86_64-w64-mingw32/lib/crt2.o:(pre_c_init)

ld.lld: error: undefined symbol: _setargv
>>> referenced by ../crt/crtexe.c:125
>>> z:/llvm-mingw-x86_64/x86_64-w64-mingw32/lib/crt2.o:(pre_c_init)
```
It behaves as if lld simply is ignoring a number of the input files.

After some digging, I've pinpointed that the issue is with file IDs. Within LLVM, `llvm::sys::fs::UniqueID`, https://github.com/llvm/llvm-project/blob/llvmorg-17-init/llvm/include/llvm/Support/FileSystem/UniqueID.h, is fairly central. This is built on the Windows File ID concept, see https://learn.microsoft.com/en-us/windows/win32/api/fileapi/ns-fileapi-by_handle_file_information:
> The identifier (low and high parts) and the volume serial number uniquely identify a file on a single computer. To determine whether two open handles represent the same file, combine the identifier and the volume serial number for each file and compare them.
> [...]
> The identifier that is stored in the nFileIndexHigh and nFileIndexLow members is called the file ID. Support for file IDs is file system-specific. File IDs are not guaranteed to be unique over time, because file systems are free to reuse them. In some cases, the file ID for a file can change over time.

In the case of LLD, it uses the `UniqueID`s to deduplicate input files. In that case, I'm not sure if it's solely a performance optimization or whether it would have a functional effect too. In other cases throughout LLVM, I'm sure the `UniqueID`s are fairly functionally essential.

To observe the issue, I've made a standalone test program that iterates over a directory and grabs the file unique IDs and inspects them for uniqueness, see https://gist.github.com/mstorsjo/74ea7b1769ae7043e0b784310a9a0d1e. Run the tool like e.g. `uniqueid.exe z:\directory`, where `z:` is a problematic file share mount. On a correctly working mount, it prints unique file IDs for all files and concludes e.g. `Iterated over 918 unique files, found 0 duplicates`, while on a problematic one, it prints e.g. `Iterated over 54 unique files, found 864 duplicates`.

In https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getfileinformationbyhandle, it is said that:
> Depending on the underlying network features of the operating system and the type of server connected to, the GetFileInformationByHandle function may fail, return partial information, or full information for the given file.
> 
> You can compare the VolumeSerialNumber and FileIndex members returned in the [BY_HANDLE_FILE_INFORMATION](https://learn.microsoft.com/en-us/windows/desktop/api/fileapi/ns-fileapi-by_handle_file_information) structure to determine if two paths map to the same target; for example, you can compare two file paths and determine if they map to the same directory.

It doesn't say how to know if it actually returned partial information, and whether the FileIndex members can be known bogus.

What's the best way forward wrt this, given how central `UniqueID`s are within LLVM? Just conclude that the tools are incompatible with file share mounts that don't fulfill this file system contract? It's perhaps not so surprising that the VirtualBox mounts fail in this way, but a bit more surprising that Microsoft's own Remote Desktop mounts expose the same issue.
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJzMWFlv28jS_TX0S8GERO0PfrCt6Bt9cBJgnDvBPAlNskj2pNnN2120rPn1F1VNbc4ymFzgYoBAobnU1qfqnG4Vgq4t4l0ye0hm6xvVU-P8XRvI-fCHu8ldebh7fIRkOiLf83-qVhYVX_3ZuhJbvrK6cKBsCY4a9AH2jYNW1w3BF-v2EFyL1Ghbg8pdT_BZ29LtQ5qM1snoPv5uLTREXUgm90m2SbJNranp87RwbZJtjvEk2caYl_a21bbeJ9lGh9BjSLLNJFvAFmpHoMBj5zyBq-BFee36ANoS-lYToSXwypauhUpp03sMsNfUQB8kPHh6-u095CpgCeScKRqlbQr3FaGXNKDUda1tnWSPsEeoXM9Z9wTUKP5BiCGB8ggejSKxNNivtEEIDT9rXW_pugQf84D-RZF2VsogN29h40zJRZXvSqi8a8VRH9BD4wLFDN4_w6_YOkJYY_hCroMkWxIGOn7TquLjc5KtIDRufw71r9yIh3AIhG109Jv21Cvz4F5BGYM1luYAygT3xjD7V2FYDSwhP8gz53WtrTLQuUDok2z19yN4_5lLuOmDdhZKZ5NsQWfvnXe5wfatWan40a6CZ9XmCrji6P_CRvz9dL4NqutQeQYWlLqq0DOwKufbwMAosUNb8oI7C_sGuSnEanC9L1BgEMDFeyeYgaaApuKyOQ-5o4YXixM1rhAcOStfnFGUwkVQEXPW2RIF7VYH0sXbJmMDhQrI7WG0_TJgWaI7tB25FnSIaDamlC4JDGCPwZkXBAXGSW-FQ5s7I_liWqdg9BcEavQZusl8NPyTP02ZGlMmk3tA753ni96WWGmL5WCN7-12AWmnum5Hh25AZzJ5F_-BRyl2EfGUpkm2KTzFX3zFtEgm96O3H_0Zh8p5cty-Lue7-TTJNvHidj-fxieTjF_UebSYpU4-XXYed8VOW00nvP7NpLrdruJ5-TMJjcerf2hKhWt_Oqnsn7hOAUn5-uXnEpr9bxK6bqstQY6NemHOCaAradug284cuJN1bZ2P3Gb7NkfPvSsz2nY9xVF0NSO-zXXbJFu8IHTadk7LGL0mPHYls1mG03YdUvismfOFUdlCMh9xHTityX04hHhRDf__y-p_97hdc1rZ44-kgBgZatp59wcWvA65cflw1_n6dry4jTU7vq5tYfoSzzee-455Kck2G23wWdglyTbHONKGw9CBB6A3ByjQkleGBy4XNUDea0PHiTwIGtjE5KFwtsCO2ERAfJONQeVt2urCu-AqGtJCe9uzkNlHU_FKQKE6nWQbrmu8suF2-OM2P-waZUuDO76z05YpSATEeQhP3glJ6BIt6UqjZ4Ixbi96rdF1A53yFIRrbCnpvDjTt8jcqJU5wqaXyjCooqUDqLjYzoICljcGoXBt1xP6FD45OPIQnjlw78B1aCFGLeLAY2DyFAJSbWQ3Llzh2py_pevgfxhj5TygKgYU8qscENMiNdim54oks4c0TZPZ-rtFEnjrACw8sWSiZ6-WV3hrS3z9hSvHHs63ntweWuRABCEFq6PyzNjbdQoD6iTQY6cIyoTSBYS3ocNCV7pIj3A6EjtB3SuvLGHUlDkOiwKONQzpVgqXY6H6gJc2o4XKI0Yq58dSEdja2OosCcJRCAyRSZTDIhfKQtEoW184-5G0eHpaSwMRy9Qgj5L56KLLRVSUWPad0axuruYRiDVFYu44flopQeg98pTj5l4ECM4wJhV06AX8tkBwHelW_ymNwDLrCD9NsHe9KYHHJWfW24LfUQawqrAgFmPiXPYxsShAjXd93bDIP86yGI6E8q3MpNhxbpxdmANgYKhrZa4q98mBE-WPF6L8PHJbVXKsgZQtlXHcERiIRV_tVTvglNArYk3Ja6Og1B4Lcv4gCK29ysN5YQfMCK4sI5sBR_JCK0seX7AYwrcHWK0Dpd_bni2mqBb5eDFfKVyMphMc5YvldDIeqZUalWNM4dfenoRvVI2iH5P5KDrWZYqvGLlz9nhKZWCGfYNeKi7P5yPuHnWUwIp08dUmK4WPPKEK59mSOcDeeZa98emA0s5rS-FYm1NrSgcYMyj2OFAik4RT1NtY_DIWfzVeXlqREsZd4ghOYA-nZE4D9DIDZ_E6rG-7mk2_42k5n177-vFO-78mpOpESDUSX14QUX6Is35IiCeq0lE9XHHU-nLPJNtbW6I3B75jkXjNoEJFsmUfJIzruBz8xrA7PJID7xxkjxJ3d4WzFou4Ez_OuP9DioP7FOnD4ReJ9NSz0KqDbID4G4_UeytcyYRzSbXZIw-ZqjdXtwU77KnWL2hliS4J6HT1u-vjdD0zFfwm5PYs3PYhUhundmKaE83EqM78lMweHn7f_XL_Yf30brfZPr3bbT9sPv76_v7T9uMHprts-XNrX8YzhZ-WI9kKAvm-IJmZl9pAVyILOkVNgFZ1_PQkBliMIyWTh0jtr6rtIpQOb6u2d7Frox2u1rWLBg9fWT_Nluv-ICgdhuFAQB1AzgRcPMoS5gFVUC8T_VT_7-CC47g8APh6BTmJHMW4hdzV_bUa_8x9wkTHX-c8-PcMSuf3ypew9xS33NnjADOOddCq36Sl_YUon2zg__tAp5F2lvQ8muP72kqFSecGLwT-5RlW_Ox4glL1ptLGSFiXEoS9kFcFsdttzKlD36guRF53zKed13JQdork4rBp8MYNGeHOWw51EMnTEyjINUHrPH5l6P0R3uKVC_3mpGwwja-di8oo4kOoOL0p7yblarJSN3g3ni-Wi-VqPF3eNHer2aQYL_PFAhfTyXI6z8dLnGUqx8VkXM5Woxt9l42yyWgyno5H49VomU5ynJRLxMVkWZXVapFMR9gqbVLelKTO1zfi8m4-no7GN0blaIKczGZZZxQxtJLJ_akrs2S2vvF3shXK-zok05HRgcLZHGkycrY77FCS2fpKVcY16zxPUnM40okeROFXS33Te3P3t_dmp0NaSes_AQAA__8GP5U5">