hippietrail
commented
1 year ago A more-or-less equivalent Rust program shares the behaviour of Zig, but Swift does not. This makes me think the dir walker code in each language's libraries does in fact need to handle firmlinks specifically and that Swift must do do. This despite claims they should be transparent to existing code.
Here's my Swift code's output:
dirwalker / LLVM
******** / ********
Library/Frameworks/Xamarin.iOS.framework/Versions/15.10.0.5/LLVM
Users/hippietrail/.vscode-insiders/extensions/ms-vscode.cpptools-1.5.1/LLVM
Users/hippietrail/.vscode/extensions/ms-vscode.cpptools-1.12.4-darwin-arm64/LLVM
Applications/Xcode.app/Contents/Applications/Instruments.app/Contents/PlugIns/DTLLVMBinaryAnalysisPlugin.xrplugin
---- all done ----And the Swift code itself. You can see there's no special code for firmlinks:
import Foundation
import AppKit
let fileManager = FileManager.default
let resKeys : [URLResourceKey] = [.isDirectoryKey, .fileSizeKey, .isSymbolicLinkKey]
let startURL: URL = URL(string: fileManager.currentDirectoryPath)!
guard CommandLine.arguments.count == 3 else {
print("** usage: dirwalker path string")
exit(1);
}
let pathArg = CommandLine.arguments[1]
let matchArg = CommandLine.arguments[2]
if let path = pathArg.addingPercentEncoding(withAllowedCharacters: .urlQueryAllowed) {
if let url = URL(string: path) {
let en = fileManager.enumerator(at: url,
includingPropertiesForKeys: resKeys,
options: [.producesRelativePathURLs],
errorHandler: { (url, error) -> Bool in
return true }
)!
mainloop: for case let fileURL as URL in en {
do {
let rv = try fileURL.resourceValues(forKeys: Set(resKeys))
if let d = rv.isDirectory, d {
let filename: String = fileURL.lastPathComponent;
if filename.contains(matchArg) {
print(fileURL.relativePath)
}
}
} catch {
print("** error 2:", error)
}
}
}
}
print("done")
xEgoist
Zig Version
0.10.0-dev.4324+c23b3e6fd
Steps to Reproduce and Observed Behavior
This is probably not a fully minimal example but I'm not fluent in Zig yet:
Run it with a starting path and a substring to search for. It will walk the directory and print out all paths that contain the substring after a
>symbol and then its resolved canonical path after a»symbol on the next line.I can only see the wrong behaviour when running in the root directory
/as macOS has several directories from/System/Volumes/Data/xlinked to/xusing "firmlinks", which is a feature of the APFS filesystem going back to Sierra. Example firmlinked directories./Library->/System/Volumes/Data/Library/Users->/System/Volumes/Data/Users/Applications->/System/Volumes/Data/ApplicationsI can't find Apple official documentation on firmlinks. Apparently they're supposed to be transparent and not affect most code. I also don't know how to get them to show up using
ls. Thelscommandline I know that will show the most extra info macOS-specific info isls -alO@ /but that doesn't seem to reveal them unlesssunlnkmeans this and only this:Sample commandline:
Actual output:
Expected Behavior
Directories should only be listed at their true locations as is the case with symlinks, not also at the locations they're firmlinked to. I believe that would look like this: