smb big sur

Thanks a lot! As for simulating an accessory on iOS isn't really all that useful I guess in my specific case this would not be a big problem, for I can either — for the time when I actually need to observe those automations, which would be limited to days, weeks at worst — keep my app foreground on an iPad; or simply run my application on a Mac, where there are no background-execution limits at all, far as I know. Thus, unless I overlook some other hurdle, this would be OK. I am a bit wary of the “large-scale projects” though: for me, this functionality is not extremely important (rather “just a bit helpful”), and if the only way to achieve it would mean to write, test and maintain heaps of complex code, I can do without (e.g., for automations triggered by HMCalendarEvents I've already wrote a tool which reads the fireDateComponents and then simply keeps track of the time; whilst there of course could be a small difference betwixt the time the trigger assumed to fire and the moment it actually did, u

Thanks for all the details and the funny anecdote. I'll ask the user to run the cp command, but they told me they have some other work to do at the moment and need a break. In the meantime, since you said it's a SMB issue, is there a way I can reproduce the Result too large myself? Yes. To start with here: Setting a large resource fork like mentioned in that StackOverflow post causes the mentioned error Argument list too long. Was this on your SMB target or on your local (APFS) volume? If this is happening on the local volume, then I think the problem is that you're hitting the max transfer size limitation of fsetxattr. You need to break the transfer up into smaller individual segments, as copyfile does here. As a side note here, there's an open question here as to how the problem file originally got to the SMB server. On modern systems, we primarily use the resource fork to store compressed data (as I described above), but we also got out of our way to NOT export that configuration

Thanks a very big lot for the detailed explanation! All clear now. You're very welcome. (I wonder if it might be perhaps worth the effort to add this information to the standard HomeKit documentation.) If you want to see this improve, please file bugs! __ Kevin Elliott DTS Engineer, CoreOS/Hardware

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 ne

Thanks for all the details and the funny anecdote. I'll ask the user to run the cp command, but they told me they have some other work to do at the moment and need a break. In the meantime, since you said it's a SMB issue, is there a way I can reproduce the Result too large myself? Setting a large resource fork like mentioned in that Stackoverflow post causes the mentioned error Argument list too long. Using the Terminal command cat file > file/..namedfork/rsrc like suggested by the first answer in that post to set the file itself as a resource fork of itself works (listing the extended attributes with ls -l@ file shows com.apple.ResourceFork 34669586 for my 34 MB test file), but calling copyfile as in the code I posted in my first post still works, even when the destination is on a FAT volume connected via SMB. When calling fsetxattr as in the code below, I can only set a custom attribute named asdf, but when using com.apple.ResourceFork the function doesn't seem to do anything. let f =

Thanks a very big lot for the detailed explanation! All clear now. (I wonder if it might be perhaps worth the effort to add this information to the standard HomeKit documentation.)

Do I do something wrong in my code? No, not really. or is that normal with some devices? Sort of. As you've noticed, both this: It seems to happen very consistently with some accessories and characteristics, not randomly; thus, it is not likely a temporary quirk in the communication with the device. and this: For some time it seemed to me it happens with bridged accessories, but not really, this hypothesis proved wrong by further testing. ...tend to be true. More specifically, what's actually going on is that there are mutually contradictory goals in the API and the (some) accessories. That is: HomeKit wants/expects accessories to respond to commands relatively quickly. To save power, some accessories want to avoid using their radio to save power. This is actually easier to understand if you reverse the question and ask what accessories DON'T have this problem. The answer is invariably powered, particularly WiFi, accessories. They're basically always awake and ready to respond to commands. Conversely, things

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

Aha, I see. I (along with the OP, it seems) got misled by the fact that they are presented through the Home application (but of course, I can see there's no reason why Home could/should not use different and probably private APIs to communicate with these, aside from its primary task to present and control the HomeKit). Keep in mind that HomePods (like AppleTVs) are HomeHubs, so there's already a control channel (either direct or over iCloud) that's relaying data between the device you’re running Home.app on and the HomePod. So the data is actually moving through that existing channel, not being sent on its own. To a large extent, that's also why the temperature sensor feature exists at all— it's not that we thought there was some great demand for integrated speaker/thermometers, it's that all of the most complicated work had already been done as part of HomeHub. Oh, I did not; I regret to admit I had considered “whatever one might want to do with all the other HomeKit temperature sensors should be possible w

Thanks for the crash report. I was able to uncover an internal bug that AFAICT is tracking the same issue (r. 154431813) [1]. Sadly, that remains unfixed and doesn’t offer any ideas as to how you might avoid it. My advice is that you file your own bug about this, attaching all the information you have available. Please post your bug number, just for the record. Also, you mentioned that you’re in touch with some users that can reproduce this. If so, could you ask them to file their own report about it in Feedback Assistant. That should capture a sysdiagnose log, which might help with the investigation. If that happens, ask them to send you their bug number and then post those here as well. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] Much to my own surprise. Radar is a very big haystack (-:

[quote='813810021, iRIG, /thread/813810, /profile/iRIG'] I’m wondering if there is [an] API for Apple Notes? [/quote] No. [quote='813810021, iRIG, /thread/813810, /profile/iRIG'] I just saw once that it’s possible through a Apple Script on Mac. [/quote] Correct. [quote='813810021, iRIG, /thread/813810, /profile/iRIG'] But the problem for me is that the app should also run on iOS. [/quote] My advice is that you file an enhancement request for a Notes API, similar to the APIs we have for Calendar (EventKit), Contacts (Contacts framework), and so on. Please post your bug number, just for the record. Using an AppleScript interface as an API is less than ideal for many reasons. One big one, as you’ve discovered, is that it’s limited to macOS. And your can’t use the equivalent technology on iOS, Shortcuts, to make progress on this. With AppleScript it’s possible to both be an AppleScript target and target other apps. With Shortcuts, you can only do the former. So, if you want to allow the user to integrate

Question1: Accessing deleted files via bookmark (Specification clarification) Our app saves file URLs as bookmarks, which file that user has selected on Files App or app-created, so to open a file which user has modified previously in the next launch. As a side note, you may want to take a look at this post which describes a longstanding issue which makes bookmark resolution much less reliable than it would be on macOS. When a user deletes a file in Files App (moves a file to Recently Deleted), the app can still resolve the bookmark and access the file for read/write operations. Is this behavior intended? In other words, is it correct that a bookmark can access a file that has been deleted in Files App but not permanently removed? Yes. Bookmarks are a relatively low-level file system construct compared to the Recently Deleted concept Files.app presents. As far as the bookmark system is concerned, it's just another file on disk. Question2: Overwriting a file in Recently Deleted (Potential bug) We noticed that

Is there an officially supported way for third-party iOS apps to access accelerometer data at sampling rates higher than ~100 Hz? So, my first question here is why you think you need a higher sampling rate? I ask because every developer who's asked this question has done so having gone through the same general development experience: They built an initial motion analysis engine which sort of worked, but had strange/inconsistent results and/or glitches. They increased the update interval and the situation improved marginally, but not completely. They continued increasing the update interval and saw improvements without actually resolving the issue until they hit the limit. Based on that experience, they've decided that the problem is caused by update frequency and if they can JUST get data a little bit faster everything will work fine. The problem here is that, in my experience, that entire analysis was built on the fundamentally false premise that the update frequency was actually the source of the problem. I

But the funny thing is, I just tried to reproduce it again because you requested the sysdiagnose logs and ... today the issue is gone. The helper now works just fine on this Mac too. This is speculative, but this is a kind of thing that happens when there are issues with the LaunchServices database. That database is how the system maps bundle IDs to file system locations, which can obviously be a problem if/when something goes wrong in the database. These issues often have exactly the kind of pattern you’re describing— something stays broken quite persistently, then suddenly starts working for no apparent reason. I have an extended post about this sort of issue here, however, the two points I’d pull from that post: While I've seen these issues happen to many developers, they're much, MUCH rarer on end-user systems. The unique dynamics of the development process are the single biggest factor here. The fact this keeps happening is a side effect of LaunchServices’ basic role, NOT a lack of attention or maintenan