Fix a corner case where createDirectory would fail on windows #1479

daveinglis · 2025-08-22T17:34:23Z

The //?/ prefix needs to be added to directories if the length is greater than MAX_PATH - 12, however the PATHCCH_ALLOW_LONG_PATHS to PathAllocCanonicalize would only do that if the path was greater than MAX_PATH. This change uses PATHCCH_ENSURE_IS_EXTENDED_LENGTH_PATH, which forces it on all the time. Just needed to remove the prefix in a few places as it was making it way out into tests as this is suppose to be transparent to the user.

This also fixes createDirectory() withIntermediateDirectories: true for long paths on Windows.

closes #1486

daveinglis · 2025-08-22T19:01:08Z

@swift-ci please test

daveinglis · 2025-08-25T17:01:28Z

@swift-ci please test

daveinglis · 2025-08-27T18:15:39Z

@swift-ci please test

jmschonfeld · 2025-08-28T20:52:19Z

Sources/FoundationEssentials/FileManager/FileManager+Directories.swift

+            func createDirectoryRecursively(at directoryPath: String) throws {
+                // Check if directory already exists
+                var isDirectory: Bool = false
+                if fileExists(atPath: directoryPath, isDirectory: &isDirectory) {


I think this could open us up to TOC-TOU issues. Since we're already handling ERROR_ALREADY_EXISTS below when we try to create the directory, can we just elide this check and let the error handling of CreateDirectoryW take care of the rest? (I know the error handling below also feels TOC-TOU-like, but given we can't know if the pre-existing result was a directory in the same call, it seems better to have a TOC-TOU issue when deciding whether to throw the error than deciding whether to create the directory to begin with)

yep, that makes sense, will update.

so Im rethinking this.... This first check is recursively walking the parent looking for where to start creating the folders, without it, it would always walk to the root, creating the folders from there, this seems it could be quite the performance hit if this first check is removed, would it not?

The previous implementation didn't have this check, right (just confirming it's not a performance regression from a previous release to remove it)? I agree it would be more work, but it seems like that's probably correct work to do since the system doesn't have an API that does this in one call atomically, right? As unfortunate as performing a bit more work is, I think minimizing the potential security issues that typically come with TOC-TOU discrepancies is important here even if it means we need to do more work because we can't check for the optimal case first.

@jmschonfeld Ok, I have updated this to just use the CreateDirectoryW result to determine if it already exists walking done the tree, then back up once it exists or is created.

@jmschonfeld Are we good with this now?

Thanks this LGTM now (but would appreciate a double check on this from @compnerd before merging just to make sure everything else looks good)

Sources/FoundationEssentials/FileManager/FileOperations.swift

Tests/FoundationEssentialsTests/FileManager/FileManagerTests.swift

Sources/FoundationEssentials/String/String+Internals.swift

Sources/FoundationEssentials/FileManager/FileManager+Directories.swift

daveinglis · 2025-09-02T15:06:32Z

@swift-ci please test

daveinglis · 2025-09-02T15:20:21Z

@swift-ci please test

jakepetroules · 2025-09-03T17:52:19Z

Sources/FoundationEssentials/String/String+Internals.swift

                var pwszCanonicalPath: LPWSTR?
-                let flags: ULONG = PATHCCH_ALLOW_LONG_PATHS
+                // Alway add the long path prefix since we don't know if this is a directory.
+                let flags: ULONG =  PATHCCH_ENSURE_IS_EXTENDED_LENGTH_PATH


Do we not also need the PATHCCH_ALLOW_LONG_PATHS flag anymore?

@daveinglis Also, the same code is copied to:

swift-system

swift-build

swift-subprocess

There are also variations in swift-tools-support-core and swift-testing.

Can you open PRs to make the change there as well?

The PATHCCH_ALLOW_LONG_PATHS is not needed, PATHCCH_ENSURE_IS_EXTENDED_LENGTH_PATH will always prepend the //?/

So I saw the swift-build version, but it's never used in the context of creating a directory so should work fine as is. I can look at the other packages but if the usage is never used with creating directories do we still need it changed?

So I saw the swift-build version, but it's never used in the context of creating a directory so should work fine as is. I can look at the other packages but if the usage is never used with creating directories do we still need it changed?

You never know when it might be used in new contexts, and because of cargo-culting I think we want to ensure that the most-correct implementation is kept in sync across all places it's copied to.

Ideally we'd have one function that everything could call into, but not a great place for this sort of SPI...

ok, I will start putting up some PR for the other version so that all match.

daveinglis · 2025-09-04T20:30:36Z

@swift-ci please test

jrflat · 2025-09-11T02:50:46Z

Sources/FoundationEssentials/FileManager/FileManager+Directories.swift

+                                return // Directory now exists, success
+                            }
+                        } else if lastError == ERROR_PATH_NOT_FOUND {
+                            let parentPath = directoryPath.deletingLastPathComponent()


.deletingLastPathComponent() will replace all \ with / in the path, but I think it's OK since the next call to .withNTPathRepresentation will call GetFullPathNameW and normalize them back to \. I was curious if this might cause issues if someone passes a path that already has a \\?\ prefix to .createDirectory(atPath:), which would then have parent paths of the form //?/..., but I ran some simple tests and it still seems to work OK. We could add a .replacing(._slash, with: ._backslash) to the end to be safe.

The //?/ prefix needs to be added to directories if the length is greater than MAX_PATH - 12, however the PATHCCH_ALLOW_LONG_PATHS to PathAllocCanonicalize would only do that if the path was greater than MAX_PATH. This change uses PATHCCH_ENSURE_IS_EXTENDED_LENGTH_PATH, which forces it on all the time. Just needed to remove the prefix in a few places as it was making it way out into tests as this is suppose to be transparent to the user. This also fixes createDirectory() "withIntermediateDirectories: true" for long paths on Windows.

daveinglis · 2025-09-15T16:15:36Z

@swift-ci please test

…swiftlang#1479)" This reverts commit aa97b79.

…#1479)" (#1512) This reverts commit aa97b79.

tshortli · 2025-09-16T15:50:26Z

Reverted by #1512 because this broke the Windows build for Swift CI.

…swiftlang#1479)" (swiftlang#1512) This reverts commit aa97b79.

daveinglis requested a review from jakepetroules August 22, 2025 17:34

daveinglis force-pushed the fix_long_window_paths branch from f0af396 to d5ffb8a Compare August 22, 2025 18:31

daveinglis force-pushed the fix_long_window_paths branch from d5ffb8a to 1bf3406 Compare August 25, 2025 16:59

daveinglis force-pushed the fix_long_window_paths branch from 1bf3406 to 9192a96 Compare August 27, 2025 17:54

daveinglis requested review from compnerd and jmschonfeld August 28, 2025 19:03

jmschonfeld reviewed Aug 28, 2025

View reviewed changes

jmschonfeld requested a review from jrflat August 28, 2025 21:04

compnerd reviewed Aug 28, 2025

View reviewed changes

Sources/FoundationEssentials/String/String+Internals.swift Outdated Show resolved Hide resolved

jakepetroules reviewed Aug 28, 2025

View reviewed changes

Sources/FoundationEssentials/FileManager/FileManager+Directories.swift Outdated Show resolved Hide resolved

daveinglis force-pushed the fix_long_window_paths branch from 9192a96 to e8e3ead Compare September 2, 2025 15:04

daveinglis force-pushed the fix_long_window_paths branch from e8e3ead to d9a17bb Compare September 2, 2025 15:11

jakepetroules reviewed Sep 3, 2025

View reviewed changes

daveinglis force-pushed the fix_long_window_paths branch from d9a17bb to 3ec5ddc Compare September 4, 2025 20:28

daveinglis requested a review from jmschonfeld September 5, 2025 13:17

jmschonfeld approved these changes Sep 10, 2025

View reviewed changes

jrflat reviewed Sep 11, 2025

View reviewed changes

daveinglis force-pushed the fix_long_window_paths branch from 3ec5ddc to 6b787ac Compare September 15, 2025 16:15

daveinglis merged commit aa97b79 into swiftlang:main Sep 15, 2025
19 checks passed

jrflat added a commit to jrflat/swift-foundation that referenced this pull request Sep 16, 2025

Revert "Fix a corner case where createDirectory would fail on windows (…

27e2ace

…swiftlang#1479)" This reverts commit aa97b79.

tshortli pushed a commit that referenced this pull request Sep 16, 2025

Revert "Fix a corner case where createDirectory would fail on windows (…

039c330

…#1479)" (#1512) This reverts commit aa97b79.

chloe-yeo pushed a commit to chloe-yeo/swift-foundation that referenced this pull request Sep 22, 2025

Revert "Fix a corner case where createDirectory would fail on windows (…

ad15d72

…swiftlang#1479)" (swiftlang#1512) This reverts commit aa97b79.

daveinglis mentioned this pull request Sep 23, 2025

Strip any UNC long path prefix from _wgetcwd swiftlang/swift-corelibs-foundation#5267

Open

Fix a corner case where createDirectory would fail on windows #1479

Fix a corner case where createDirectory would fail on windows #1479

Uh oh!

Conversation

daveinglis commented Aug 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

daveinglis commented Aug 22, 2025

Uh oh!

daveinglis commented Aug 25, 2025

Uh oh!

daveinglis commented Aug 27, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

daveinglis Aug 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

daveinglis commented Sep 2, 2025

Uh oh!

daveinglis commented Sep 2, 2025

Uh oh!

jakepetroules Sep 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

daveinglis commented Sep 4, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

daveinglis commented Sep 15, 2025

Uh oh!

Uh oh!

tshortli commented Sep 16, 2025

Uh oh!

Uh oh!

daveinglis commented Aug 22, 2025 •

edited

Loading

daveinglis Aug 29, 2025 •

edited

Loading

jakepetroules Sep 3, 2025 •

edited

Loading