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.
* Advise porter on where to make necessary change.
In #1075 the change was already made for BSD (thank you!); my working
edit had this guidance to ensure future porters get an error directing
them where to make a necessary change.
Otherwise, the FoundationEssentials build will fail and complain these
variables are not defined but not have guidance as to where they are
sourced from.
* OpenBSD does not support extended attributes.
* OpenBSD does not have secure_getenv.
* Remaining OpenBSD changes.
* OpenBSD also needs `pthread_mutex_t?`.
* Originally I followed Darwin's check with `d_namlen`, but this should
work too.
* Correct statvfs type casts for OpenBSD.
On OpenBSD, fsblkcnt_t -- the type of f_blocks -- is a UInt64; therefore,
so must `blockSize` be.
Ultimately, both sides of the `totalSizeBytes` multiplication should
probably be type cast for all platforms, but that's a more significant
functional change for another time.
* Default activeProcessorCount to 1, not 0.
After a rather tedious debugging session trying to figure out why
swiftpm-bootstrap appeared to be deadlocked, this turned out to be the
culprit. Perhaps this should be #error instead, but for now, set a
sensible default.
* Use sysconf for activeProcessorCount.
This is what Dispatch does in some places for OpenBSD anyway, so do
likewise here.
* FreeBSD platform specific fixes
- Use "/usr/share/zoneinfo"
- Use platform specific types and values
- Implement extattr ops for FreeBSD
- Use copy_file_range(2) for file cloning
* Revise patch to ProcessInfo to reduce potential impact to other platforms
* Fix macOS build
* typo
* take suggested change
* Gate `fchown` and `fchmod` calls behind `os(WASI)`
They are not available on WASI, so we gate them behind `os(WASI)`.
* Add missing constant shims for wasi-libc
* Use `futimens` instead of legacy `futimes`
wasi-libc does not provide `futimes` as it is a legacy function.
574b88da48/libc-top-half/musl/include/sys/time.h (L34)
* 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>
* Port directory enumeration related code to WASI
For now wasi-libc does not include fts(3) implementation, so mark
features depending on it as unsupported on WASI. Once wasi-libc includes
fts or we decide to implement and maintain our own fts-like API, we can
remove these `#if os(WASI)` guards.
wasi-libc issue tracking fts support:
https://github.com/WebAssembly/wasi-libc/issues/520
Also, wasi-libc defines some constants in a way that ClangImporter can't
understand, so we need to grab them manually through _FoundationCShims in
function call form.
* Delegate error throwing decisions to the delegate
* 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.
WASI doesn't have `sendfile`, so we need to implement the copy in user
space with `read` and `write`. It's not as efficient as `sendfile`, but
it's the best we can do.
* 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.
This adjusts the API usage to account for differences on Android. The
biggest source of difference is the nullability, particularly in the
`fts` APIs. Unfortunately, `MMAP_FAILED` is not imported by the clang
importer due to the casting involved so we manually inline the constant
at the single site.
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.
Adjust the Windows path for copying (or linking) files. This adds the
missing recursion in the copy (the documentation for `CopyFile2` was not
clear that the recursive copy is not performed).
Rather than relaying the underlying system error, replace the error with
the expected error code. This repairs the test case expectation of the
thrown error.
In the case that the destination exists, we should check for continue
after error. If the source does not exist, simply do nothing.
Furthermore, adjust the test to ensure that we are using the path
spelling rather than the FSR.
Take the opportunity to correct an error in the tests where we would not
check the correct captured item set.
When running the test suite we would hit an infinite loop due to the use
of the relative path rather than the absolute path for accessing the
attributes of the file entry.
The condition of the error check was inverted as it was meant to be a
`guard` statement. This was resulting in an infinite loop. With this we
now pass a few additional tests and the test suite no longer hangs.
This adds an initial implementation for file operations on Windows. With
this, `FileManager` should at least build on Windows, which unblocks
future work as well as brings us closer to enabling
`FoundationEssentials` on Windows.
This allows us to get further into building FoundationEssentials once
again on Windows. Much of the file system work has resulted in this
module no longer being viable on Windows and will need to be replaced to
allow building on Windows which does not have the `fts` APIs.
* (123438249) FileManager.removeItem does not throw error when encoutering long paths
The change makes swift-foundation FileManager.removeItem properly throw
on removefile(3) errors.
* Conform POSIXError to Error
* Clean up warnings and produce more detailed test failures
* Fix macOS CI failure
