refactor: replace SwiftNIO filesystem backend with system APIs#291
Closed
refactor: replace SwiftNIO filesystem backend with system APIs#291
Conversation
pepicrft
changed the title
pepicrft
changed the title
… I/O Replace raw POSIX/WinSDK system calls with coenttb/swift-file-system, which provides concurrency-pooled async I/O to prevent file descriptor exhaustion under heavy load. This addresses ulimit issues hit in tuist/tuist. Platform minimum bumped to macOS 26 / iOS 26.
URL.path() on Windows returns /C:/... which is invalid for Win32 APIs. Strip the leading slash when a drive letter follows. Also use URL(fileURLWithPath:) on Windows for consistent file URL construction.
Bump Docker images to swift:6.2, Windows to swift-6.2-release, and macOS runners to macos-26 for Xcode 26 / Swift 6.2 support.
swift-file-system's Delete uses stat() which follows symlinks, causing failures when deleting directories containing symlinks whose targets don't exist. Implement our own lstat-based recursive delete that handles symlinks correctly by unlinking them directly.
SetFileTime, DeleteFileW, and RemoveDirectoryW return Bool on Windows Swift, not Int. Remove the != 0 comparisons.
macos-26 runners are not yet available. Use macos-15 with explicit Xcode 26 beta selection instead.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This PR removes the package's
SwiftNIOfilesystem backend and replaces it with direct system file APIs while preserving the current public API and platform support.It also migrates the package test suite to Swift Testing and adds coverage around the behavior most likely to regress during the backend swap.
Context
We investigated adopting Coen ten Thije Boonkkamp's
swift-file-systemto address the file-handle-management issues in this package.That path was not a good fit for this library today:
The final branch keeps the existing package surface and support matrix, but removes the
SwiftNIOdependency and the oldFileManager-heavy implementation underneath it.What Changed
SwiftNIOdependency from the packageFileSystembackend with POSIX and WinSDK-backed operations for directory traversal, temporary directories, touch, mkdir, move, copy, replace, recursive delete, metadata, timestamps, and symlinksZIPFoundation, but implemented archive traversal withoutFileManager.default.zipItemGlobtraversal to use system directory iteration instead of the previousFileManagerpathAlternatives Considered
The main alternative was to keep the
swift-file-systemadoption and raise the package floor to match it. I decided against that because it would introduce breaking support changes for a dependency swap that can be handled internally.I also considered keeping parts of the old Foundation-based implementation, especially around ZIP operations, but that would have left the file-handle-management concerns only partially addressed.
Testing
swift testswift build -c releaseI did not run Linux or Windows builds locally.
One remaining limitation is that the larger
FileSystemTestssuite is still excluded on Windows, so Windows runtime confidence still relies more heavily on CI than on local execution.