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.

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

@swift-ci please test

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

@swift-ci please test

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-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?

jmschonfeld · 2025-08-28T20:57:17Z

Sources/FoundationEssentials/FileManager/FileOperations.swift

@@ -139,6 +139,9 @@ extension FileManager {
    fileprivate func _shouldRemoveItemAtPath(_ path: String) -> Bool {
        var delegateResponse: Bool?
        if let delegate = self.safeDelegate {
+#if os(Windows)
+            let path = path.removingNTObjectNamespacePrefix()


This same pattern is used in a lot of delegate calls such as _shouldCopyItemAtPath, _shouldLinkItemAtPath, and _shouldMoveItemAtPath. If it's possible for the file system to contain a file that uses such a path, should we standardize all of these to remove the NT prefix before calling the delegate?

ya, I thought about this but I couldn't see how any of the other delegates would get a prefixed path since none of them passes it in, and I didn't want to add any extra unnecessary overhead. If you feel strongly Im fine with updating the other delegate calls.

Ah I see - that's one part that I wasn't sure of. In what cases do we create paths with the new prefix? Is it just implementations that happen to call through withNTPathRepresentation directly (is that why remove file is different, since it calls the delegate with the NTPath representation instead of the result of withUnsafeFileSystemRepresentation)?

ya, looking at this again, I may be able to fix up the caller so the correct path is aways passed.

jmschonfeld · 2025-08-28T21:03:11Z

Tests/FoundationEssentialsTests/FileManager/FileManagerTests.swift

@@ -1195,8 +1193,13 @@ private struct FileManagerTests {

            #expect((cwd + "/" + dirName + "/" + "lnk").resolvingSymlinksInPath == (cwd + "/" + dirName + "/" + fileName).resolvingSymlinksInPath)

-            #expect(throws: Never.self) { try fileManager.createDirectory(at: URL(fileURLWithPath: dirName + "/" + "subdir2"), withIntermediateDirectories: false) }
-            #expect(throws: Never.self) { try fileManager.createDirectory(at: URL(fileURLWithPath: dirName + "/" + "subdir2" + "/" + "subdir3"), withIntermediateDirectories: false) }
+            #expect(throws: Never.self) { try fileManager.createDirectory(at: URL(fileURLWithPath: dirName + "/" + "subdir1"), withIntermediateDirectories: false) }


This creation of <dirName>/subdir1 looks like it was moved from the above, but line 1181 still uses this directory. Was this an intentional move, or can this be moved back to ensure that the expectation on line 1181 (changing the CWD to <dirName>/subdir1) still runs when subdir1 exists?

good catch, I think I move one too many lines, will fix

compnerd · 2025-08-28T21:23:11Z

Sources/FoundationEssentials/String/String+Internals.swift

+    /// normalize such paths to standard format.
+    ///
+    /// - Returns: A string with the NT object namespace prefix removed, or the original string if no prefix is found.
+    package func removingNTObjectNamespacePrefix() -> String {


I think that we should call this removingNTDevicePathPrefix. The NT Object prefix would be \??\.

Or maybe just "removingNTPathPrefix", more similar to the underlying API.

If we can trust Wine's implementation to match Windows, it looks like this removes the following prefixes:

\\?\UNC\

\\?\

There's also the device path prefix \\.\ which PathCchStripPrefix does NOT handle - I checked - and I'm not sure is relevant or would be correct to strip here.

will update

jakepetroules · 2025-08-28T21:26:06Z

Sources/FoundationEssentials/FileManager/FileManager+Directories.swift

            GetCurrentDirectoryW(DWORD($0.count), $0.baseAddress)
        }
+
+        // Handle Windows NT object namespace prefix
+        // The \\??\ prefix is used by Windows NT for device paths and may appear


The prefix is spelled \\?\ (you have an extra question mark)

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

jakepetroules reviewed Aug 28, 2025

View reviewed changes

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

Are you sure you want to change the base?

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!

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!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

daveinglis commented Aug 22, 2025 •

edited

Loading

daveinglis Aug 29, 2025 •

edited

Loading