On Windows, there is a built-in maximum path limitation of 260 characters under most conditions. This can be extended to 32767 characters under either of the following two conditions:
- Adding the longPathAware attribute to the executable's manifest AND enabling the LongPathsEnabled system-wide registry key or group policy.
- Ensuring fully qualified paths passed to Win32 APIs are prefixed with \?\
Unfortunately, the former is not realistic for the Swift ecosystem, since it requires developers to have awareness of this specific Windows limitation, AND set longPathAware in their apps' manifest AND expect end users of those apps to change their system configuration.
Instead, this patch transparently prefixes all eligible paths in calls to Win32 APIs with the \?\ prefix to allow them to work with paths longer than 260 characters without requiring the caller of Foundation to manually prefix the paths.
See https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation for more info.
* (146349351) Support NS/CFURL re-core in Swift
* Fix .fileSystemPath() calls in Windows test
* Use encoded strings for .absoluteURL, fix NSURL bridging and CFURL lastPathComponent edge cases
* Add workaround for crash on Linux
* Fix typo
* Revert "Revert "rdar://142693100 (Allocationless constant String -> NSString bridging via a new tagged pointer type) (#2798)" (#2843)"
This reverts commit c378439322f5b960ecb972b27ab1419a622ad6b2.
* Adopt the new entry point for bridging the new tagged pointers
* All remaining callsites passed null-terminated strings, so just eliminate the isTerminated bit and simplify further. Also gets us up to 13 bits of length
* Address review comments
* [wasm] Make `FileManager.createFile()` work on WASI
fixesswiftwasm/swift#5593
`FileManager.createFile()` currently doesn't work on WASI because it
requires `.atomic`, it requires creating a temporary file, and it isn't
suppported on WASI.
So I have fixed that by removing the `.atomic` requirement only on WASI.
* [wasm] Make `Data.WritingOptions.atomic` unavailable on WASI
`writeToFileAux`, `createTemporaryFile`, and `createProtectedTemporaryFile` also become unavailable on WASI.
* Add an upcall point to swift-corelibs-foundation for String encoding conversion
* Add upcall for conversion from bytes to String in non-swift-foundation encodings
* (133687793) Prevent buffer over-reads with string file system representations that fail
Signed-off-by: Jeremy Schonfeld <jschonfeld@apple.com>
* Account for empty buffers
Signed-off-by: Jeremy Schonfeld <jschonfeld@apple.com>
* Move empty buffer check earlier
Signed-off-by: Jeremy Schonfeld <jschonfeld@apple.com>
---------
Signed-off-by: Jeremy Schonfeld <jschonfeld@apple.com>
* Get FoundationEssentials building
Adding the missing musl imports to get FoundationEssentials building for
the Swift static SDKs again.
Also providing an option to disable building the macros. The macros
aren't necessary for building the library and will not be run as part of
the static SDK. No need to bloat the SDK or build times further. For
Swift 6, the macros should be provided by the toolchain since the
toolchain and SDK are current revlocked due to swiftmodules.
* Get FoundationInternationalization building
Adding the missing Musl imports to get FoundationInternationalization
building for the static SDK.
* [android] fix the LP32 armv7/i686 android build
* Update Sources/FoundationEssentials/Android+Extensions.swift
Co-authored-by: Jeremy Schonfeld <1004103+jmschonfeld@users.noreply.github.com>
* drop the android Lp32 specific operator &
---------
Co-authored-by: Jeremy Schonfeld <1004103+jmschonfeld@users.noreply.github.com>
* Add `import WASILibc` statements to libc import chains
* Declare wasm32 arch as 32-bit environment
* Switch to _pointerBitWidth for architecture checks
This change switches the architecture checks in Data.swift to use the
_pointerBitWidth instead of the arch() checks for consistency with newer
platforms.
* Guard out user/group related code on WASI
This change guards out the user/group related code on WASI, as WASI does
not have the concept of users or groups.
* Throw explicit unsupported error if trying to set user or group on WASI
Instead of implicitly ignoring user-given values, we should throw
exception to make it clear that those values cannot be set on WASI.
* Standardize backslashes before string path processing on Windows
* Call _standardizingSlashes() from normalizedPath(with:)
* Return self when possible on non-Windows
This adds the necessary guards and includes for the Android modules.
While the module does not compile currently due to nullability
differences (and in some cases missing declarations), this at least
brings the module to a point where we can start working on the errors
and differences to create a maintainable codebase for Android.
When trying to get the file system representation of a string, we may
have previously used `appendingPathComponent(_:)` which will have used
the incorrect separator. Ensure that all the separators are properly
converted prior to returning the path.
