“Popping Sound”

While this isn't the answer I had been wishing for it does give me a lot of food for thought. Thanks The Eskimo for looking into it! [quote='874248022, DTS Engineer, /thread/814022?answerId=874248022#874248022'] When it rotates a file, the system calculates how fast it filled up. [/quote] So wrt this note, I understand it's more complicated than just rotating a single file, but still it sounds like everyone writing into the Unified Logging system can contribute to this. It strikes me at least one strategy (if not a preferable one), is to disable logging for all other processes/subsystems (even some of the native OS processes) that tend to be noisy too? Of course this is meant as a temporary and desperate measure, in theory it should raise our survival chance? And another thought, what if we disable persisting, but then have an external party help redirect our logs to be persisted? I first thought the xctrace record --template Logging might be a good candidate for this task but later found out the def

Hello Kevin, hello All I have tested your suggestions. Sadly to no avail. The location of the files is not crucial nor using a signed version of the app. I have also setup a new project on my macOS14 Mac with the same result. So it is not a macOS26 problem neither. That makes me wonder more and more. My AppStore app (bcAnalyze) that does use the related file feature with these files works well on any macOS with these files. The code I am using is older dating back ca. 10 years (originated in Obj-C days and is now Swift since ca. 4 years). The idea of adding a security scoped bookmark to the sidecar file is tempting, but wouldn't help since the original application producing the the sidecar file is more than 10 years old and users may have already millions of file pairs. There shouldn't be a difference between SwiftUi and AppKit as front-end, but I may also try this in the next days. Since my AppStore app works, I must oversee something little that has this big effect. I can't otherwise explain the negative re

Hi Ziqiao, thanks for the reply. Let me explain the situation I'm facing with my CloudKit-powered app. Device A and B are both fully synced with the cloud. On Device A, the user deletes a bunch of records and continues to use the app, letting the app sync in the background. The user waits a few weeks before opening the app on Device B. When they open the app, it attempts to sync. The change token is expired, so it retrieves all of the records on the server. My app is designed to treat this as if this is the user's first sync (a unify sync), so it compares all records on the server with all local records, then uploads any local records missing from the cloud and downloads any cloud records missing from the local database. At this point, all of the items deleted in step 2 have been re-downloaded onto Device B. Currently, my app never checks deletedRecordIDs on a unify sync. An easy fix would be to start processing this array even on unify syncs. But from your reply, it sounds like this will be an empty

Right now I've got the same error and don't know how to handle it. But in my case I'm recording audio on the Apple Watch with AVAudioEngine. I minimized the app during recording and started 1sec timer. When timer fires, I'm getting interruption began event where I pause recording, when I stop timer's alarm, I have interruption end event with shouldResume and I'm trying to do AVAudioEngine.start(). That's where I have this error.

Sorry for the confusion, and you assumed correctly that copying in the Finder works, but I actually meant something else. What I meant was this: a user of my app reported that when my app copies files from a QNAP NAS to a folder on their Mac, they get the error Result too large. When the app copies the same files from the Desktop folder, it works. Copying the files with the Finder, regardless of their source location, works as well. Yes, that all makes sense. There are basically two different issues that work here: There appears to be a bug in SMB involving the handling of larger xattr. The issue is specific to smb, which is why this doesn't affect local file copies. The Finder uses its own copy engine, which bypasses the problem. More specifically, the Finder is almost certainly using the ..namedfork/rsrc accessor that StackOverflow post mentions. Covering a few details: Interestingly, the destination file is actually created but has a much smaller size than the source: 250 KB instead of 34 MB. The initial f

Right. This is werder than I thought. It IS connecting to the USB microphone, but is applying a brickwall filter to the audio, cutting off everything above 30kHz. I need to talk to somebody at Apple about this behaviour.

Sorry for the confusion, and you assumed correctly that copying in the Finder works, but I actually meant something else. What I meant was this: a user of my app reported that when my app copies files from a QNAP NAS to a folder on their Mac, they get the error Result too large. When the app copies the same files from the Desktop folder, it works. Copying the files with the Finder, regardless their source location, works as well. From what the user told me, the issue only happens with some files. I actually asked them to narrow the issue down as much as possible and they found a folder with a single file, and copying that folder always causes that error. Interestingly, the destination file is actually created but has a much smaller size than the source: 250 KB instead of 34 MB. The user also shared that file as a zip archive on Dropbox with me. I ran the ls -l@ command on it to see its extended attributes and their size, the output was: com.apple.FinderInfo 32 com.apple.ResourceFork 286 com.apple.quarantine 5

Thank you a lot - I will try this weekend - I am at a client location right now - but when back I test and tell the results! Thanks a lot for the various ideas! Sounds good. Good luck and please let me know what you find. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

A user of my app reported that when my app copies files from a QNAP NAS to a folder on their Mac, they get the error Result too large. When copying the same files from the Desktop, it works. Clarifying what you mean here, are you saying that the Finder can handle the copy and while your app cannot? Or that your app is doing both copies it works to one destination (the Finder) and fails to another? Or something else? I'm going to assume the Finder works and your app fails (that's what typically happens) but please correct that if I'm wrong. I asked them to reproduce the issue with the sample code below and they confirmed that it reproduces. They contacted QNAP for support who in turn contacted me saying that they are not sure they can do anything about it, and asking if Apple can help. Can someone at Apple say anything about this? I spent some time looking into this and there does appear to be a newly reported issue (r.165759954) that sounds similar to this. In terms of next steps, I have a few sugges

It sounds like you're aware of what a routing app is, but just to confirm details: A routing app provides navigational directions between two locations. It is enabled inside of an Xcode project by going to the Capabilities tab, and adding the Maps capability, which will then show you a list of checkboxes for the transportation modes by which you're able to provide navigational directions between points. Those checkboxes correspond to values added to your Info.plist file under a key named MKDirectionsApplicationSupportedModes. It sounds like you're not providing directions, but you should check to make sure the above capability isn't enabled accidentally. And if you're not providing directions, also don't enable this capability just to try and solve this error, as I've seen people get tangled up further by trying that. If all of that looks good and that capability wasn't accidentally enabled, then the next thing you should do is to open a bug report with the details of your App ID and the bui

[quote='874071022, ball-hayden, /thread/807938?answerId=874071022#874071022, /profile/ball-hayden'] It's interesting that your guide says DevForums is not an official support channel, [/quote] That confusion is my fault, alas. Historically, DTS provided two forms of support: Formal support via technical support incidents Informal support, via the forums, mailing lists, and so on In 2024 we changed that process, putting a lot more emphasis on the forums. That way the results of our work are available to the entire developer community. As part of that we renamed technical support incidents to code-level support requests. Quinn’s Top Ten DevForums Tips was written before the 2024 change, meaning it originally used the old language. I tweaked the text slightly when that change rolled out, but re-reading it today it’s obvious that it wasn’t sufficiently clear. I’ve just updated the post to improve this. [quote='874071022, ball-hayden, /thread/807938?answerId=874071022#874071022, /profile/ball-hayden'] It sounds