Post

Replies

Boosts

Views

Activity

fopen() fails when trying to open file stored in iCloud Drive
I have a collection of .pcap files in iCloud Drive that I need to parse using low level C APIs. To open the file, I need to use fopen(). However, it appears that when the file hasn't been downloaded/sync'ed, meaning it's in iCloud but not yet on disk, then fopen() fails with "No such file or directory." I thought fetching the file from iCloud would be transparent to any file system APIs, including low-level C APIs, when trying to open the file, but that doesn't seem to be the case. If I use NSOpenPanel first to choose the file from iCloud Drive and then pass the path to fopen(), it works because NSOpenPanel triggers the file's download. But, in the scenario I'm testing, I'm trying to drag and drop the file from Finder, retrieving the path to the file from the pasteboard, and passing it to fopen(), but that doesn't work unless the file has already been sync'ed/downloaded from iCloud. What would be the right way to ensure that fopen() works with files stored in iCloud Drive? Thanks, Adrian
2
0
953
Jan ’21
How to hide NSTrackingSeparatorToolbarItem after collapsing view?
Hi, I'm trying to implement a split view controller with 3 views: a sidebar, a master view, and a "right" sidebar. The tracking separator for the sidebar works as expected when collapsing the sidebar, meaning it's not visible when the sidebar is collapsed. However, I'm trying to achieve the same behavior for a second tracking separator (set to track divider index 1) but I'm unable to have the separator not showing when the view is collapsed. I was assuming the behavior was automatic. If the view is not collapsed, the tracking separator appears in the toolbar, otherwise, it does not. That doesn't seem to be the case. Is it because there are other items to the right of the separator? Do I have to hide the separator myself or reposition the other toolbar items to the left of the separator when collapsing the view? Any ideas are appreciated. Thanks.
1
0
745
Sep ’20
Notarization has stopped working for .pkg files
Hi,Notarization of .pkg files has stopped working for me. Basically, the .pkg file is notarized but the contents are not. The notarization log shows the following response:{ "logFormatVersion": 1, "jobId": "[jobId-edited]", "status": "Accepted", "statusSummary": "Ready for distribution", "statusCode": 0, "archiveFilename": "WiFiExplorerPro_2.3.pkg", "uploadDate": "2019-10-25T22:34:38Z", "sha256": "[sha256-edited]", "ticketContents": [ { "path": "WiFiExplorerPro_2.3.pkg", "digestAlgorithm": "SHA-1", "cdhash": "[cdhash-edited]" } ], "issues": [ { "severity": "warning", "code": null, "path": "WiFiExplorerPro_2.3.pkg", "message": "This archive is corrupt, and cannot be unpacked for analysis.", "docUrl": null, "architecture": null } ] }The same packaging/notarization workflow was working for me two weeks ago but now it ends up with this error. Well, a warning, but the error comes later when trying to staple the .app inside the .pkg, since it wasn't notarized. As far as I know, nothing changed on my side, as I said, it's the same process to generate the .pkg and notarize it. By the way, the .app can be notarized by itself, separately, so it's not an error when notarizing the .app. The .pkg file works fine, it can be launched, and passes all checks with regards to codesigning and notarization. Howerver, notarization is saying the archive is corrupt.Are there any other log files produced by the notarization process that I can review?Any hints on what could be wrong here?Thanks,Adrian
12
0
2.3k
Oct ’19