That does sound like a bug to me. Can you make a self-contained test case and
file at https://bugs.swift.org/ <https://bugs.swift.org/> ?
Thanks!
Jordan
> On Jun 29, 2017, at 14:00, Marco S Hyman via swift-users
> <swift-users@swift.org> wrote:
>
> This macOS code in Xcode 8.3.3:
>
> if !fileManager.fileExists(atPath: (saveFileURL.path)) {
> do {
> 1 ==> try fileManager.linkItem(atPath: url.path, toPath:
> saveFileURL.path)
> 2 ==> } catch {
> // couldn't create hard link, copy file instead
> do {
> 3 ==> try fileManager.copyItem(at: url, to: saveFileURL)
> } catch let error as NSError {
> unexpected(error: error,
> "Cannot copy \(url.path) to
> \(saveFileURL.path)\n\nReason: ")
> return false
> }
> }
> }
> return true
>
>
> lldb tells me the code at 1 fails. That was expected. The app is sandboxed
> and the security bookmark code that gives access to the destination is in
> flux. lldb says control transfers to 2 then falls into the do block
> containing 3.
>
> The code at 3 fails for the same reason. This is when the unexpected
> occurred. lldb says that control transferred to 2 then to the end of the if
> statement where the function returns true. The catch following the do
> containing the function “unexpected” is not entered.
>
> Is that a bug?
>
> As for why 1 uses path instead of URL an older version of the code had this
> note.
>
> // linkItemAtURL fails trying to link foo.jpg_original to somedir/foo.jpg.
>
>
> _______________________________________________
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
