file uri scheme

[quote='856443022, DTS Engineer, /thread/797469?answerId=856443022#856443022'] No, I'm talking about withoutImplicitStartAccessing. We explicitly say it does not apply to security-scoped bookmarks: [/quote] This option causes an implicit call to startAccessingSecurityScopedResource() on the returned URL when it’s ready to use the resource. The way this is written makes it sound like there will be a call to startAccessingSecurityScopedResource somewhere, so that a subsequent pair of explicit startAccessingSecurityScopedResource and stopAccessingSecurityScopedResource will still leave access at 1, leaking kernel resources. It his not the case? Is this consistent across macOS and iOS? This option isn’t applicable to security-scoped bookmarks. The documentation phrasing isn't clear about whether it's talking about NSURLBookmarkResolutionWithSecurityScope specifically (which is only available on macOS), or if it also applies to iOS (where all bookmarks are security scoped AFAIU from your earlier messages). Can you

We found the cause - this happens when extension returns content of different size (even larger) than the range for fetchPartialContents. In our case it happened quite rarely and the content was always larger - which is quite surprising looking at the docs in NSFileProviderPartialContentFetching.h: On-disk layout: (...) The file contents outside of the fetched range are ignored by the system. (...) For instance, if the fetchedRange is {offset:0x100000, length:0x1000} (...) The ranges {0, 0x100000}, and {0x101000, EOF} can be anything including sparse ranges. So actually in this example, if I understand correctly what fetched range refers to, if EOF > 0x101000 (i.e. fetched data extends beyond the range), the issue reproduces. FWIW leaving some more details in case it's useful for someone reading this: Analyzing sysdiagnose logs was quite helpful - in logs from log show --archive system_logs.logarchive we noticed this extent length is not as expected (524488 != 524288) and based on that quickly fou

Hmmm, that’s the human readable file. Do you have the JSON version of it? The file you attached here shows the format I’m looking for. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='866814022, TataChaitanya, /thread/805809?answerId=866814022#866814022, /profile/TataChaitanya'] I am trying this as part of authorisation plug-in only. [/quote] Quoting myself here: [quote='865561022, DTS Engineer, /thread/805809?answerId=865561022#865561022'] There’s no supported way to do this. [/quote] and: [quote='865561022, DTS Engineer, /thread/805809?answerId=865561022#865561022'] My advice is that you file an enhancement request [/quote] I can answer your specific questions, but those answers won’t change this conclusion. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='807782021, RickHedin, /thread/807782, /profile/RickHedin'] I don't understand why. [/quote] Yeah, that’s confusing. macOS has two keychain implementations, the file-based keychain and the data protection keychain. See TN3137 On Mac keychain APIs and implementations for more about this. The security tool puts the password into the file-based keychain. In Keychain Access that shows up in login. The Passwords app is centred around the data protection keychain, and hence doesn’t see it. There is no command-line tool access to the data protection keychain. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='807898021, SadCat, /thread/807898, /profile/SadCat'] plain (non-bundled) executables that request screen recording access no longer appear [/quote] Indeed. I’ve seen reports of this for Full Disk Access — see this thread — but didn’t realise that it was affecting other TCC settings as well. IMO this is a bug and I encourage you to file it as such. When you’re done, post your bug number so that I can associate it with the bugs that originated from the Full Disk Access side of things. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='807854021, nikhil2701, /thread/807854, /profile/nikhil2701'] this doesnt use the new structured concurrency. [/quote] Right. It was written before the new API was release and I haven’t updated it yet because most folks who want to do this need to support iOS 18, where the new API isn’t available. Oh, and I haven’t had time |-: [quote='807854021, nikhil2701, /thread/807854, /profile/nikhil2701'] I am particularly interested … TLS with PSK encryption support [/quote] AFAIK that’s not currently supported (r. 159170556)-:. I’d appreciate you filing an enhancement request for that. While we have a bug about it already, it’s an internal bug, and bugs from third-party developers can help in situations like this. Please post your bug number, just for the record. [quote='807854021, nikhil2701, /thread/807854, /profile/nikhil2701'] switching between Wifi and peer to peer interface [/quote] I’m not sure I understand that. Please elaborate. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Supp

Good afternoon. Example links: https://app-site-association.cdn-apple.com/a/v1/xn--montral-fya.ca https://xn--montral-fya.ca/.well-known/apple-app-site-association Reference number: FB21076762 Additionally, during testing we observed the following: When adding any domain containing xn-- anywhere in the string to the Associated Domains entitlements, the system does not attempt to fetch the AASA file.

[quote='865567022, siracusa, /thread/804395?answerId=865567022#865567022, /profile/siracusa'] My app also has a default Main Menu in its Main.storyboard file because it has a setting to decide if the app should show a Dock icon and menu bar or not (honored by callingNSApp.setActivationPolicy(…) at runtime). I get these warnings about the default menus in the main menu bar when my app launches. [/quote] It seems I get these too! I wasn’t looking at what my app was logging right after launch. The app I forked had a feature like this one in SwitchGlass. I had stripped out that feature, among so many others, but was considering add it back and so left the .nib in the app. So a good guess might be that any LSUIElement app nevertheless with a main menu logs these warnings. The similar warnings about my NSStatusItem menu, it seems they however are no longer being emitted under 26.2 beta (sadly I didn't check 26.1). So if one datapoint can be extrapolated into a trend, perhaps the main menu logs will eventua

Hi Kevin, TL;DR (Core Issues) 100% Reproducible: We used two completely independent test methods (cp + sync and fio buffered mode), and both consistently reproduced the data corruption issue under Buffered I/O. Clear Failure Threshold: Both tests point to the exact same failure boundary: file sizes 128MB (inclusive) and below pass, but 256MB (inclusive) and above consistently fail. Key Clue Confirmed: The fio test again reported the exact same error as our initial finding: data corruption starts at a very precise offset 1048576 (1MB) location. You mentioned last time that this offset was odd; now we can confirm this is not a coincidence, but a core characteristic of the problem. Test 1: System-Level File Copy Integrity Test (cp + sync) This test aims to simulate standard user operations to rule out tool-specific issues. Methodology: We used a shell script to automate cp for file copying, used sync to force the system to flush I/O caches, and finally compared the SHA256 hashes of the