User Profile

Recently simulators have not been able to be downloaded from Xcode, after endlessly trying the transfer rate was well below 100kb/s and would fail after a short while. The speed was on average 100x slower than other servers with the exception of a short spike of passable speeds. Because Xcode for some reason doesn't support resuming simulator downloads, I downloaded the simulators directly from the dvtdownloadableindex file using two different methods but the fileSize values consistently differed slightly from the downloaded files. This resulted in a Missing Signature error when adding the simulator with xcrun simctl runtime add.

There is a macFUSE bug that can result in an Input/output error - https://github.com/osxfuse/osxfuse/issues/45 when listing a directory. In most cases this doesn't cause any major issues, just a "ls: mount: Input/output error" message when running ls. The problem is that the contentsOfDirectory(at:includingPropertiesForKeys:options:)  now does not work, however, the contentsOfDirectory(atPath:) method does. There appears to be a difference in how these methods handle errors, although the documentation doesn't seem to suggest this. The following code returns an array of strings without an error: FileManager.default.contentsOfDirectory(atPath: "/Users/user") The following code results in an error: FileManager.default.contentsOfDirectory(at: URL.init(fileURLWithPath:"/Users/user"), includingPropertiesForKeys: nil) REPL: $E3: NSError = domain: "NSCocoaErrorDomain" - code: 256 { _userInfo = 3 key/value pairs { [0] = { key = "NSURL" value = "file:///Users/user/mount" } [1] = { key = "NSFilePath" value = "/Users/user/mount" } [2] = { key = "NSUnderlyingError" value = } } } Xcode: Error Domain=NSCocoaErrorDomain Code=256 "The file “mount” couldn’t be opened." UserInfo={NSURL=file:///Users/user/mount, NSFilePath=/Users/user/mount, NSUnderlyingError=0x600000289740 {Error Domain=NSPOSIXErrorDomain Code=5 "Input/output error”}} Passing [] as the includingPropertiesForKeys value gives the same result. It's also interesting that in the REPL the NSUnderlyingError value is missing.