Skip to content

user: align Windows mkdir behavior with Unix - #236

Open
thaJeztah wants to merge 1 commit into
moby:mainfrom
thaJeztah:user_windows_align
Open

thaJeztah wants to merge 1 commit into
moby:mainfrom
thaJeztah:user_windows_align

Conversation

@thaJeztah

Copy link
Copy Markdown
Member

The Windows implementation of mkdirAs was originally introduced as a minimal wrapper around os.MkdirAll because ownership is not supported on Windows and the uid/gid parameters were only needed to keep the daemon starting.

As a result, MkdirAndChown would also create missing parent directories, unlike the Unix implementation.

Use os.Mkdir when mkAll is false to preserve the documented semantics, while retaining the simplified Windows implementation for ownership and permissions.

Originally introduced in moby/moby@bfe252b78184, which added a Windows-specific implementation to work around limitations on that platform;

A recent change to use pkg\idtools causes a chown to be on the
startup path of the daemon. Chown is not supported on Windows,
hence the daemon would not start.

Copilot AI review requested due to automatic review settings July 23, 2026 10:34

This comment was marked as off-topic.

@kolyshkin

Copy link
Copy Markdown
Collaborator

@thaJeztah looks like golangci-lint is not too happy with the changes

@thaJeztah
thaJeztah force-pushed the user_windows_align branch 2 times, most recently from 4d6ae4d to 7ee622a Compare September 2, 2026 10:14
@thaJeztah
thaJeztah force-pushed the user_windows_align branch 2 times, most recently from 9ef7b0f to 405c4bb Compare September 14, 2026 08:57
@thaJeztah
thaJeztah requested a lite review from Copilot September 14, 2026 08:57

This comment was marked as resolved.

This comment was marked as outdated.

@thaJeztah
thaJeztah force-pushed the user_windows_align branch 6 times, most recently from e87e767 to 70f6df5 Compare September 14, 2026 11:53
@thaJeztah
thaJeztah requested a lite review from Copilot September 14, 2026 11:55

This comment was marked as resolved.

This comment was marked as resolved.

The Windows implementation of mkdirAs was originally introduced as a
minimal wrapper around os.MkdirAll because ownership is not supported on
Windows and the uid/gid parameters were only needed to keep the daemon
starting.

As a result, MkdirAndChown would also create missing parent directories,
unlike the Unix implementation.

Use os.Mkdir when mkAll is false to preserve the documented semantics,
while retaining the simplified Windows implementation for ownership and
permissions.

Originally introduced in [moby/moby@bfe252b78184][1], which added a
Windows-specific implementation to work around limitations on that
platform;

> A recent change to use pkg\idtools causes a chown to be on the
> startup path of the daemon. Chown is not supported on Windows,
> hence the daemon would not start.

[1]: moby/moby@bfe252b

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔵 Needs a closer look

Address the non-atomic directory creation race before approval.

Review details

Suppressed comments (1)

user/idtools_windows.go:25

  • The initial Stat and this Mkdir are not atomic: if another process creates path after the stat reports it missing, os.Mkdir returns EEXIST even though path is now a directory. That violates MkdirAndChown's documented nil-on-existing-directory behavior and is a regression from MkdirAll's race handling. Attempt Mkdir first and re-stat its error to accept a directory (while retaining the ENOTDIR result for files).
	return os.Mkdir(path, 0)
  • Files reviewed: 3/3 changed files
  • Comments generated: 0 new
  • Review effort level: Lite

@thaJeztah

Copy link
Copy Markdown
Member Author

The initial Stat and this Mkdir are not atomic: if another process creates path after the stat reports it missing, os.Mkdir returns EEXIST even though path is now a directory. That violates MkdirAndChown's documented nil-on-existing-directory behavior and is a regression from MkdirAll's race handling. Attempt Mkdir first and re-stat its error to accept a directory (while retaining the ENOTDIR result for files).

Had this initially, but then changed it to use the same order as on Linux; we can look at the linux code if we want to do a second check on errors, but that can be done separately.

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.

3 participants