“file uri scheme”

Hello Giroux, miamitwinz, This is an issue we're aware of (FB22272504), but we're not aware of any recommended workaround so far. If you find something that helps you avoid the issue, please share it with the community by posting it here. Even though we're aware of this issue, we still encourage you to open a bug report, and post the FB number here once you do. The specific info you include your bug report might help our investigation, and filing the bug report you to get notified when it is resolved. Bug Reporting: How and Why? explains how you can open a bug report. Thank you for reporting, Richard Yeh  Developer Technical Support

Shouldn't it be supported? Yes, it should be. Have you filed a bug on this and, if so, what's the bug number? Also is there a way to disable spotlight indexing on a mounted folder? I believe adding a file named .metadata_never_index at the root of the volume will prevent this. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Whenever you see a regression like this with a new OS version, especially in the betas, the best course of action is to file a Bug Report.

Hi @41772ki , to help reproduce the issue, could you please confirm the specific OS version you’re testing on? Also please file a feedback report using Feedback assistant and include a sample code and the recording of how to reproduce the issue. Once you’ve done this, please share the feedback ID number here. Thanks!

The issue isn't just with CKSyncEngine. I have a custom CloudKit-based syncing setup, which uses CKRecordZoneSubscription to listen and respond to changes in a zone, and the remote notifications aren't working with that either. I filed FB22380044 ... hopefully this can be patched up with a quick update, as it would break so many apps

Thanks Quinn, that was exactly the right pointer. We traced through the disassembly of xzm_main_malloc_zone_init_range_groups on macOS 26.3.1 and correlated it with the open source in rel/libmalloc-792 (xzone_segment.c:1210-1250). Here's what we found: The CONFIG_MACOS_RANGES path computes: ptr_reservation_size = XZM_RANGE_SEPARATION + XZM_POINTER_RANGE_SIZE + XZM_RANGE_SEPARATION = 4G + 16G + 4G = 24 GiB ptr_start = 16GiB + (entropy % 736) * 32MiB It then calls mach_vm_map with VM_FLAGS_FIXED for 24 GiB at ptr_start. The 736 granules cover [16 GiB, 39 GiB), ensuring the reservation fits under the 63 GiB commpage limit. Why dylibs land above 16 GiB: The binary is a Chromium component-build test binary (browser_tests) that loads 516 Chromium dylibs plus system libraries (1543 images total). The main executable alone consumes 5.54 GiB of VA (4 GiB __PAGEZERO, 517 MiB __TEXT, 1.04 GiB __LINKEDIT). The 516 Chromium dylibs add another 10.19 GiB of aggregate VM (2.26 GiB __TEXT, 3.86 GiB __LINKEDIT). Combined with

The latter. I will file a feedback report for user related behaviour change.

[quote='882312022, dopey, /thread/820940?answerId=882312022#882312022, /profile/dopey'] We are actually seeing seeing this happen in practice. [/quote] OK. [quote='882312022, dopey, /thread/820940?answerId=882312022#882312022, /profile/dopey'] it's not deterministic. [/quote] Right. It’s hard to say what’s going on without more logging, but the most likely cause is a memory pressure exit, and that’s very non-deterministic. [quote='882312022, dopey, /thread/820940?answerId=882312022#882312022, /profile/dopey'] I will open a bug and post the bug number. [/quote] Much appreciated. Ideally this would include a sysdiagnose log taken: On a device with extra CryptoTokenKit logging enabled (see below) Shortly after seeing the problem But that might be hard to get, so you should feel free to file a bug with only your ‘kill ctkd’ step as evidence. On the logging front, our Bug Reporting > Profiles and Logs only has a CryptoTokenKit profile for iOS. However, you can install that profile on macOS, and I think

Hi Quinn, Following up on your earlier advice about using NEAppProxyUDPFlowHandling and the async readDatagrams / writeDatagrams API. I’ve updated my DNS proxy as follows: I now implement NEAppProxyUDPFlowHandling and handle DNS over UDP via the async API. For each flow, I store the Network.NWEndpoint that comes from readDatagrams() and then pass that same endpoint back into writeDatagrams. I no longer use NWHostEndpoint / NetworkExtension.NWEndpoint anywhere in this path. Relevant code (stripped down): private func readFirstDatagrams(from udpFlow: NEAppProxyUDPFlow, into flow: Flow, channel: Channel) { Task { let (pairs, error) = await udpFlow.readDatagrams() if let error = error { // handle error... return } guard let pairs = pairs, !pairs.isEmpty else { // retry... return } let (firstData, firstEndpoint) = pairs[0] let size = firstData.count MainLogger.shared.log(message: UDP recv (pairs.count) datagrams, first size=(size) from=(firstEndpoint) type=(type(of: firstEndpoint)) ) // Force a hostPort endpoint l

The 3 in that error is KERN_NO_SPACE, which is a pretty clear indication that the system memory allocator asked for address space and the kernel refused to give it. However, given all the constraints you’ve described, it’s not at all clear why that would be. Weirdly, the code that traps this way is not on the main branch of the Darwin open source, but I found a copy in the rel/libmalloc-792 branch [1]. Now, I don’t have time today to study that code in depth, but I figured you’d find it interesting (-: AFAICT it tries to allocate address space by using mach_vm_map to map MEMORY_OBJECT_NULL, specifying a start that’s after 16 GiB, such that it fits within 64 GiB, with a randomly applied offset. That random bit probably explains why this shows up so infrequently. It’s hard to say why this is failing. You might be able to learn more by running vmmap against the dying process. It’d also be interested to know what address was passed to mach_vm_map (with reference to the source, that’s the ptr_addr value), somethin