Skip to content

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
    • Help
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
CMake
CMake
  • Project
    • Project
    • Details
    • Activity
    • Releases
    • Cycle Analytics
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Charts
  • Issues 2,211
    • Issues 2,211
    • List
    • Board
    • Labels
    • Milestones
  • Merge Requests 19
    • Merge Requests 19
  • External Wiki
    • External Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Charts
  • Create a new issue
  • Commits
  • Issue Boards
  • CMake
  • CMakeCMake
  • Issues
  • #18359

Closed
Open
Opened Sep 11, 2018 by Roger Leigh@rleigh
  • Report abuse
  • New issue
Report abuse New issue

execute_command: File open mode for pipe leads to poor interoperability (other readers can't open file read-only)

Context: this ticket

This codebase ultimately calls CreateFileW to open a file on Windows: here

However, the unit tests fail when run from ctest/cmake in parallel. They are run from execute_process here which is driven by a helper which is used like this.

The tests only fail when run in parallel with tests opening stdin using the same input file. It looks like this code in cmake is at fault: kwsys/ProcessWin32.c:

    cp->PipeChildStd[0] =
      CreateFileW(wstdin, GENERIC_READ | GENERIC_WRITE,
                  FILE_SHARE_READ | FILE_SHARE_WRITE, 0, OPEN_EXISTING, 0, 0);

It's the presence of GENERIC_WRITE/FILE_SHARE_WRITE for a read-only use of the file, which breaks other read-only uses.

Looking at KWSys.git, it looks like it's been this way from 396f866c to ed7f53e0.

I can see from the commit message that this was done originally to allow simultaneous writing, so this is really a heads up that this causes problems of its own. Looking at the Windows file documentation I'm unsure what a useful general solution would be. This seems entirely Windows-specific; Unix isn't a problem in this respect, it's solely down to the Windows file access semantics being rather restrictive.

Edited Sep 11, 2018 by Roger Leigh
Assignee
Assign to
3.13.0
Milestone
3.13.0
Assign milestone
Time tracking
None
Due date
No due date
1
Labels
os:windows
Assign labels
  • View project labels
Reference: cmake/cmake#18359