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.
GetBinaryType will return ERROR_BAD_EXE_FORMAT when querying an arm64 executable from an x86 process running on an ARM system. This change switches the implementation to use SHGetFileInfoW, which isn't subject to this quirk.
This also makes isExecutableFile behave more similarly to other platforms -- e.g. isExecutableFile already returns true for any file with the execute bit, even for an arm64 executable on an x86_64 macOS system (which it can't actually run). The spirit of the API is that the file is of an executable type, not necessarily that the running system is capable of executing it.
The practical consequence of fixing this bug is that queries like:
```swift
FileManager.default.isExecutableFile(atPath: "C:\\Windows\\system32\\cmd.exe")
```
will now correctly return true regardless of what architecture the binary is compiled for or what type of system it's running on.
Closes#860
* 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.
* [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.
* 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)
* Fix 'var currentDirectoryPath: String' crash when the directory is removed.
* Fix test failed in Windows
* Fix test failed in Windows
* Update testCurrentWorkingDirectory() for Windows
* Fix merge mistake
* Update Tests/FoundationEssentialsTests/FileManager/FileManagerTests.swift
Co-authored-by: Jeremy Schonfeld <jeremyschonfeld@gmail.com>
---------
Co-authored-by: Jeremy Schonfeld <jeremyschonfeld@gmail.com>
On Windows, we could potentially return a `nil` for the current working
directory in the rare case that the current working directory was
changed during the computation:
```swift
let dwLength: DWORD = GetCurrentDirectoryW(0, nil) // 1
return withUnsafeTemporaryAllocation(of: WCHAR.self, capacity: Int(dwLength)) {
if GetCurrentDirectoryW(dwLength, $0.baseAddress) == dwLength - 1 { // 2
return String(decodingCString: $0.baseAddress!, as: UTF16.self)
}
return nil // 3
}
```
Consider the case where at step 1, we receive $n$. We then are
interrupted, the CWD changed. We then perform step 2, where we receive
$m$ (st $m != n$). We would then proceed to point 3, where we return
`nil`. Avoid this TOCTOU issue by repeating this operation to a fixed
point.
Because we are guaranteed a current directory on Windows (unless the
initial query for the buffer size fails), we will eventually succeed. In
order to avoid a DoS attack vector, limit the attempt to quiescence to a
fixed number.
* [Android] Enable more code and tests
while disabling setting extended file attributes and a test creating a hard link,
features not normally allowed on Android.
* Remove incorrect WASI check
* 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 commit guards out the extended attributes and file system
attributes related code on WASI as WASI does not support these
features. Just return nothing or ignore the set request.
* Use dynamic replacement instead of _typeByName for internationalization upcalls
* Make FOUNDATION_FRAMEWORK function non-dynamic
* Fix build failures
