I cannot find any information online about Apple dropping support for this, but I also cannot make it work, and it wouldn’t surprise me if they view localized folder names as a security problem.
Trying to save a file as /path/to/symlink will fail with “file does not exist” using the new NSFileManager API, even when the symbolic link does point to an existing file.
NSFileManager’s approach is inferior to exchangedata(), but as this feature is no longer supported with Apple’s default file system (APFS), there is little reason to maintain our own implementation of the fallback code required when we cannot use exchangedata(), especially as the OS know more about file references (aliases), metadata, and other stuff that should be preserved when writing a new (replacement) file.
In theory the NSFileManager strategy can fail to create the temporary destination, in which case we will pass NULL to open() and crash.
Will fix this in a later commit.
The intermediate_t type now wraps the actual saving strategy to make it easier to change strategy based on the destination file system, user preferences, or other factors.
Based on crash reports, some of these functions do fail in practice, mainly due to “too many open file descriptors”, in which case we should let the io::spawn function fail, rather than crash the program.
The io::spawn function is used (amongst others) to update SCM status, so a failure is not always worth notifying the user about (beyond logging an error).
The code is about how to display items in the file browser (package, folder, alias, non-browsable volume, etc.) so it makes sense to limit the visibility of this API.
The textClipping file is saved as a binary plist on 10.11 and 10.12 (I could not verify 10.10) so we can eventually replace the use of FSRef here as well.
Unlike path::swap_and_unlink we do not try to use exchangedata() since support for this is missing from the upcoming AppleFileSystem, so it would seem to be somewhat deprecated.
This was previously used by the software updater to prevent the “temp cleaner” from removing a downloaded update, incase the user took their time to click the “Install & Relaunch” button.
There doesn’t seem to be any replacement API for this so while the warning (when building with the 10.8 SDK) may serve as a reminder to update the code, the only possible update I can see is to drop support for reading text clippings.
Crash is in CFStringGetLength called from _CFURLCreateWithFileSystemPath, so it appears that some sort of malformed string can find its way to this call.
