getFileId() error in windows docker container

[willenbr24]

We are using cppcheck in a Windows Docker container (windowsservercore-20H2) and have noticed that the function simplecpp::FileDataCache::getFileId() does not work.

This is because the Windows API function GetFileInformationByHandleEx is not available in the Docker container (Error 50: ERROR_NOT_SUPPORTED). We also tested this on windowsservercore-ltsc2025, but the problem persists there as well.
Because of this problem, cppcheck cannot find files and therefore does not work.

However, it works when using the simpler API function GetFileInformationByHandle (without Ex).
Here is my fix for the problem:

#ifdef DOCKER
// New implementation
    BY_HANDLE_FILE_INFORMATION fileInfo;
    const BOOL ret = GetFileInformationByHandle(hFile, &fileInfo);
    if (ret) {
        id.fileIdInfo.VolumeSerialNumber = static_cast<std::uint64_t>(fileInfo.dwVolumeSerialNumber);
        id.fileIdInfo.FileId.IdentifierHi = static_cast<std::uint64_t>(fileInfo.nFileIndexHigh);
        id.fileIdInfo.FileId.IdentifierLo = static_cast<std::uint64_t>(fileInfo.nFileIndexLow);
    }
#else
// Old implementation
    const BOOL ret = GetFileInformationByHandleEx(hFile, FileIdInfo, &id.fileIdInfo, sizeof(id.fileIdInfo));
#endif

The problem can also be reproduced using testrunner.exe.

[firewave]

Thanks for reporting.

The documentation of the function does not give any indication it might not be available in certain configurations - see https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-getfileinformationbyhandleex.

I reckon the way to get that image is docker pull mcr.microsoft.com/windows/servercore:ltsc2025 according to https://learn.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/container-base-images.

[willenbr24]

Thank you for your quick response.
Yes - you can pull the image with docker pull mcr.microsoft.com/windows/servercore:ltsc2025.

When I run testrunner.exe inside this image, several tests fail — for example, the TestPreprocessor::testMissingInclude test.
However, with my modification above (specifically, using a different API call), the test runs successfully.

I also tested the mcr.microsoft.com/windows/server:ltsc2025 image, since Microsoft states that it provides full API access. Unfortunately, the same problem occurs there as well.

(To run the application in the Docker container, you naturally need the necessary runtime libraries. In my case, that's vc_redist.x64.exe.)

[firewave]

I also tested the mcr.microsoft.com/windows/server:ltsc2025 image, since Microsoft states that it provides full API access. Unfortunately, the same problem occurs there as well.

I did not expect that.

I drilled further into the documentation regarding the requested information class FileIdInfo: https://learn.microsoft.com/en-us/windows/win32/api/winbase/ns-winbase-file_id_info. That states that it is only supported by Windows Server and not by the client. So it should actually be the other way around that it should only be working on your setup.

Since the documentation of the call in question refers to several filesystems I wonder if it is tied to that. Maybe the Docker container is not using NTFS?

There is a discussion here which seems to support my assumption: python/cpython#104820.

IIRC the windows-* GitHub runners recently switched from the C:\ to the D:\ so the build is done on a drive different from the one the actual system lives on.

[firewave]

Ugh. GitHub only supports Docker images with Linux-based runners and the images cannot be deployed on such. So that requires manual work (or some existing action) to be able to integrate it into the CI.

I think the way to fix this is to call the the *Ex() function first and fallback to the more generic one if it fails.

I would also like to get the implementation out of the header first since spill platform-specific stuff into all code. I have a local branch for that already.

CC @glankk

[firewave]

I am not able to get this to work.

Out-of-the-box you can only run Linux containers (I am getting the same message in the CI):

> docker container run mcr.microsoft.com/windows/servercore:ltsc2025 .\simplecpp.exe
Unable to find image 'mcr.microsoft.com/windows/servercore:ltsc2025' locally
docker: Error response from daemon: no matching manifest for linux/amd64 in the manifest list entries: no match for platform in manifest: not found

To be able to run Windows ones you need to switch the daemon to the Windows one (see https://learn.microsoft.com/en-us/virtualization/windowscontainers/quick-start/run-your-first-container#pull-a-container-base-image).

After that I am still not able to run it locally:

> docker container run mcr.microsoft.com/windows/servercore:ltsc2025 .\simplecpp.exe
Unable to find image 'mcr.microsoft.com/windows/servercore:ltsc2025' locally
ltsc2025: Pulling from windows/servercore
docker: no matching manifest for windows(10.0.19045)/amd64 in the manifest list entries

So it seems you need a different OS to be able to run such containers.

[danmar]

@firewave Maybe the docker engine is running in "Linux mode" and you need to switch to "Windows".

https://stackoverflow.com/questions/65149702/docker-desktop-cannot-switch-to-windows-container

As far as I know.. if it is able to start a linux container then it runs in "Linux mode".

[firewave]

@firewave Maybe the docker engine is running in "Linux mode" and you need to switch to "Windows".

That is exactly what I did and outlined above with the daemon switch.

[danmar]

That is exactly what I did and outlined above with the daemon switch.

aha. understood. I am surprised that it's not supported. if you see some option to pay for some external VM and solve this let me know (AWS would be preferable).

[firewave]

if you see some option to pay for some external VM and solve this let me know (AWS would be preferable).

We should not pay for this. I also do not think it is necessary as the amount of Windows API usage is next to none.

It might be possible to reproduce this locally by using files non-NTFS filesystems like SMB/CIFS via a network share or FAT32 via an USB stick (I have both handy). And maybe that can be done within a GitHub action as well. And maybe WSL can be leveraged (still need to look into that regarding the absolute path stuff anyways). I will give it a go after the weekend since I will be out most of the day.

[firewave]

I can reproduce it on an exFAT filesystem but not an a network share (I was access the machine itself via the share so that might not have actually gone through SMB).

We should probably extend GetFileId() to return a more detailed error.

[firewave]

I can reproduce it on an exFAT filesystem.

I am actually getting a different error code for GetFileInformationByHandleEx(). It fails with 87 which is ERROR_INVALID_PARAMETER. So we are dealing with different causes. The fix is probably the same but it would be nice if I could reproduce your issue as well.