Posts

Post not yet marked as solved
4 Replies
I looked at Swift a few times ... I think not liking XCode is not helping πŸ˜‰ Cool thing about Lazarus: cross platform development works great (most of the time). OK, coming back to the real (other) issue; So I grabbed you Swift code and that worked on both Intel and Arm - as expected. Now comes the kicker, which makes me feel a little stupid, ... I ran my own code again and guess what ... it works without modification (did a full shutdown last night). I don't know what to tell you ... I either goofed up (not impossible), or the reboot helped ... Either way; I guess that solves that ... thanks Quinn! Very much appreciate you chiming in πŸ‘πŸ» Just for other non-Swift developers, add these imports to the beginning of Quinn's code. Took me a second to realize this - thanks again Quinn! 😊 import Foundation import NetFS
Post not yet marked as solved
4 Replies
Haha, that's funny - now you made me look for that T-Shirt 😜 Just kidding though. I do not dislike C ... I just liking Pascal better 😁 Thank you for replying! To answer your questions: Yes, this is an GUI app, started from Finder with double click (not a command line application). Scheme used for testing: smb Some additional testing on my end: I took the effort this morning to write a tiny dedicated test application to test the NetFSMountURLSync parameter variations. And all these variations work on the Intel Mac (macOS 12.6): URL: smb://username:password@serverip/sharename username null, password null, mount path null, kNAUIOptionNoUI enabled, kNetFSMountAtMountDirKey enabled URL: smb://serverip/sharename username set, password set, mount path null, kNAUIOptionNoUI enabled, kNetFSMountAtMountDirKey enabled URL: smb://serverip/sharename username set, password set, mount path /Users/username/mountpoint, kNAUIOptionNoUI enabled, kNetFSMountAtMountDirKey enabled URL: smb://username:password@serverip/sharename username null, password null, mount path /Users/username/mountpoint, kNAUIOptionNoUI enabled, kNetFSMountAtMountDirKey enabled I tried all of these additionally with kNetFSMountAtMountDirKey disabled (mount options null), with open_options null, with kNAUIOptionForceUI instead kNAUIOptionNoUI and the possible combinations with these as well. All of these work on both my Intel Mac's (running 12.6, 2016 MBP and 2013 MacPro). Testing this on the 16" MBP M1 Max (also running 12.6): ALL tests fail and make the application freeze, both Intel binary and ARM64 (AARCH64) binary fail all tests. Initially the GUI freezes, then promptly the beach ball appears (not entirely unexpected when using Sync instead of ASync), then the beachball even freezes frequently and the application is just "on hold" and any sign of live from the application stops (in Console) ... For each test I get an error like the ones below (the number behind gNetAuthAuthAgentPort changes with each new test). default 13:10:02.167473+0200 project1 GetNetAuthAuthAgentPort: Calling bootstrap_look_up3() for com.apple.netauth.user.auth; uid = 501, euid = 501 default 13:10:02.167576+0200 project1 GetNetAuthAuthAgentPort: gNetAuthAuthAgentPort = 51459
Post not yet marked as solved
6 Replies
Hi John,Yep, I had not noticed it yet, but indeed I do get a "Terminal would like to access files on a removable volume" message.Even worse, using "sudo" I can't even ask for a list of the external drive.Who the heck comes up with these ideas? 😟I fully agree with you that Apple is killing developers (of said utilities) with a thousand cuts - nicely put!It is almost like Apple has a special department that comes up with ideas to take motivation away from developers.I'm not even using XCode (I really can't stand it) so you can imagine the extra hurdles I have to take to get anything done.And you're right; maybe it is time to (yet again) move to another platform or maybe even start a different hobby ...I do understand the need for more security though, but can't this be done in a more developer friendly way?I'm not paying $99/year for a certificate, for software I offer others for free, to get more and more aggravated with every release.Anyhoo - I'm still hopefull that there will be a fix for this 😊
Post not yet marked as solved
3 Replies
The problem still persists in the final release of Catalina. 😞 I've posted more details in another post - my bad for posting twice, for some reason I didn't get a notification of your reply, and I had already forgotten that I had asked this question here - my sincere apology for the late response and for posting twice.I do see that similar applications, like CCC and Etcher, experience the same issue. 😞
Post not yet marked as solved
6 Replies
Thank John for the reply! Interesting find! However, I do not see "Removable Volumes" listed on my MacBoop Pro (15" 2016) and MacBook (12") - both running public final release of Catalina (I'm assuming you're refering to the list "System Preferences" -> "Security & Privacy" -> "Privacy").If this is a leftover of a beta, then maybe Apple goofed up there, and planned this option, but removed it at the final release without correcting "Full Disk Access"? On that note, I ran the beta on my MacBook (12") which doesn't list it either.I used scripts before, and this indeed worked fine, but it did cause issues with some users.Trying to implement things the Apple recommended way, I figured that it would be at least a good idea to explore how this works and eventually implemented it. It comes with the nice side effect that the GUI becomes more responsive while executing scripts, etc as well.As for asking access from the user, I wouldn't know how to do this.i've seen 2 scenario's when it comes to "asking the user"; 1) The application accesses a function that needs permission, and macOS ask a "Allow/Do not Allow" question when the application calls this function2) When I want to install a helper tool, in which case I ask the user for authorization and macOS then handles the installation of the helper tool.Since I'm seeing CCC, Etcher, etc having similar problems, I'm wondering if this is a bug and if I should report this or not.Having said that: I'm no expert, and that's why I'm trying to find out from experts in this forum if it is a bug or just my lack of knowledge.
Post not yet marked as solved
3 Replies
Doh ... I think I found a way around this issue, even though I'm not happy about the way this is done;Open "System Preferences" -> "Security & Privacy" -> "Privacy".From the list on the left select "Full Disk Access".Click the padlock, and unlock your settings.Now click "+" to add your application to the exception list.You will have to restart your application but now writing works under Cataline without the need for running it as sudo.