Skip to content

getFileId() error in windows docker container #583

Closed

Description

@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.

Activity

  1. added 2 commits that reference this issue on Nov 10, 2025
  2. danmar commented on Nov 29, 2025

    @danmar
    Collaborator

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

    did you try with ltsc2022 ?

  3. danmar commented on Nov 29, 2025

    @danmar
    Collaborator

    I believe I managed to run ltsc2022 in a github action: #592

    Please note the "Hello from Windows container" message

    Run docker run --rm mcr.microsoft.com/windows/servercore:ltsc2022 cmd /c "echo Hello from Windows container && dir C:\"
    Unable to find image 'mcr.microsoft.com/windows/servercore:ltsc2022' locally
    ltsc2022: Pulling from windows/servercore
    425c2915a651: Pulling fs layer
    ea2e635f63c8: Pulling fs layer
    ea2e635f63c8: Verifying Checksum
    ea2e635f63c8: Download complete
    425c2915a651: Verifying Checksum
    425c2915a651: Download complete
    425c2915a651: Pull complete
    ea2e635f63c8: Pull complete
    Digest: sha256:3a2a2fdfbae2f720f6fe26f2d7680146712ce330f605b02a61d624889735c72e
    Status: Downloaded newer image for mcr.microsoft.com/windows/servercore:ltsc2022
    The filename, directory name, or volume label syntax is incorrect.
    Hello from Windows container 
    Error: Process completed with exit code 1.
    
  4. firewave commented on Nov 29, 2025

    @firewave
    Collaborator

    Thanks. I will take look later today.

  5. danmar commented on Nov 29, 2025

    @danmar
    Collaborator

    I fail to reproduce locally. Is there a suggestion what I should do? i.e. this command works fine in my windows docker container:

    simplecpp\build\debug\simplecpp.exe simplecpp\simplecpp.cpp
    

    and the integration tests are successful in my docker container also, as far as I know these tests should test out the inclusions:

    C:\danie\simplecpp>python -m pytest integration_test.py
    

    The top of the Dockerfile I used to build my docker image says:

    FROM mcr.microsoft.com/windows/servercore:ltsc2022
    
  6. danmar commented on Nov 29, 2025

    @danmar
    Collaborator

    @willenbr24 do you have suggestion how I can reproduce?

  7. firewave commented on Nov 29, 2025

    @firewave
    Collaborator

    We cannot use these Docker images in the CI - they are ginormous.

    mcr.microsoft.com/windows/servercore   ltsc2025   79967dce01f9   2 weeks ago   7.62GB
    
    mcr.microsoft.com/windows/server   ltsc2025   aec1b9526eb7   2 weeks ago   17.9GB
    

    I think trying to address the issue using manual testing via exFAT should be sufficient for now. We should file a follow-up ticket to try to automate that test.

  8. added 2 commits that reference this issue on Nov 29, 2025
    5badd89
    ed84cbe
  9. firewave commented on Nov 29, 2025

    @firewave
    Collaborator

    I think trying to address the issue using manual testing via exFAT should be sufficient for now. We should file a follow-up ticket to try to automate that test.

    This should be possible using a virtual hard disk. See
    https://learn.microsoft.com/en-us/powershell/module/hyper-v/new-vhd
    https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/gg252579(v=ws.11)

  10. added a commit that references this issue on Nov 29, 2025
    7ac711b
  11. willenbr24 commented on Dec 1, 2025

    @willenbr24
    ContributorAuthor

    @willenbr24 do you have suggestion how I can reproduce?

    I identified the issue in the cppcheck project (https://github.com/danmar/cppcheck.git) and was able to reproduce it using the unit tests (testrunner.exe). And there you can see that several tests fail, which work with my workaround.

    To reproduce the problem, you need to compile the cppcheck project inside the container and then run testrunner.exe.
    We use the Microsoft Build Tools for compilation. Instructions for installing them in Docker can be found here:
    https://learn.microsoft.com/en-us/visualstudio/install/build-tools-container?view=vs-2022

  12. firewave commented on Dec 1, 2025

    @firewave
    Collaborator

    Does this mean that the latest trunk still fails for you?

  13. willenbr24 commented on Dec 1, 2025

    @willenbr24
    ContributorAuthor

    Does this mean that the latest trunk still fails for you?

    No, I haven't tested the latest trunk yet.

  14. willenbr24 commented on Dec 1, 2025

    @willenbr24
    ContributorAuthor

    I just tested your changes from commit 7ac711b using the cppcheck project at commit cppcheck-opensource/cppcheck@a9f88d4, running the tests with testrunner.exe in a Docker container. The test was successful!
    Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions