“smb big sur”

I'm experiencing this issue. Copy file works locally for these files but fails when coming from a NAS. So, the first question here is what these files are and how they got onto that NAS. More specifically, there are basically only three reasons a file would have a resource fork today: It's really, really old. Apps were discouraged from using the resource fork from the very first release of macOS X and the Resource Manager (the only API that allowed access to it) was deprecated in macOS 10.8. Files that are intentionally using it should not be common. It's actually a compressed file. I described that case above, but the key point is that compressed files should never be leaking off of our volumes. Something else (weird) is going on which I'd love to understand. The most likely explanation here is #2, however, making that happen means something didn't work properly, which is what you should identify and correct. Works from Finder in both cases, as previously described above. Yes. For complicated historical reas

[quote='880167022, parker9, /thread/810258?answerId=880167022#880167022, /profile/parker9'] GitHub has the actual source for that version in Releases [/quote] OK. I downloaded the app, the .dSYM, and the source code and took a look. First, the crash report has this: Binary Images: 0x102c6c000 - 0x102c9ffff DIM arm64 <3e247524da7930099f63cd12ace4ab0e> …/DIM I used dwarfdump to confirm that I have the right .dSYM: % dwarfdump --uuid DIM.app/Contents/MacOS/DIM UUID: 7A4DAC69-55A2-3D1B-B9E0-6A14AB2D5EEA (x86_64) DIM.app/Contents/MacOS/DIM UUID: 3E247524-DA79-3009-9F63-CD12ACE4AB0E (arm64) DIM.app/Contents/MacOS/DIM I then symbolicated those frames: % atos -l 0x102c6c000 -o DIM.app.dSYM 0x102c799bc 0x102c8b4d4 closure #1 in ViewController.restore(_:) (in DIM) (ViewController.swift:207) thunk for @escaping @callee_guaranteed () -> () (in DIM) + 28 Plugging that into the backtrace, I get this: Thread 1 Crashed:: Dispatch queue: com.apple.root.utility-qos 0 DIM … 0x102c6c000 + 55740 closure #1 in ViewControl

Hi, my app has been validated but still not available in France because its still in verification for that point : La législation sur les services numériques. Regards

[quote='880105022, hasii2021, /thread/818406?answerId=880105022#880105022, /profile/hasii2021'] I will continue to monitor this [/quote] Please update this thread if you learn more. I try to keep track of all the weird code signing errors and what causes them — one day I’ll write a technote based on that — and I’m super curious how you’re hitting this. Oh, actually, come to think of it, you can reproduce this, so it’d be worth filing a bug about it. So, if you have the time and inclination: Create a read/write disk image that’s big enough to hold your app. Copy the app on to it. Reproduce the error. And then immediately trigger a log snapshot: % sudo log collect --last 5m Adjust the --last parameter to a bigger value if code signing takes a really log time (-: And then a sysdiagnose log. Unmount the disk image. File a bug with that disk and the logs from steps 4 and 5. Once you’re done, reply here with the bug number and I’ll see what I can uncover. But I do understand if you’re not able to do this;

@mnorton Great job! I think there might be some documentation online that can be referenced here. Reverse order well is the Big-endian issue that happens when we move from different chips. Awesome finding and great job again, can't wait to see what you do next! Albert Pascual
  Worldwide Developer Relations.

I’m confused. To start, I’m concerned about this path: [quote='818938021, chapo213, /thread/818938, /profile/chapo213'] I decided to rely only on the Team Identifier. [/quote] I don’t understand how you can trust anything about the code signature, and that includes the Team ID, if you don’t first validate the code signature. Next, in cases like this I usually ask about the big picture. And on that subject you wrote: [quote='818938021, chapo213, /thread/818938, /profile/chapo213'] In my application I validate the authenticity of my own binaries [/quote] Programs can’t authenticate themselves. If an attacker is able to modify your code, they can also remove or subvert any checks that you add. What problem are you trying to solve here? ps On iOS I usually point folks at App Attest, but I’m presuming that you’re on the Mac. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

My signed and notarized Electron app has this exact issue. I can replicate is on macOS Tahoe 26.3.1. I see the bug was reported about 8 months ago, and it's still not fixed. This is quite a big problem for apps like mine. It's a very poor and unintuitive UX to expect users to toggle an obscure security setting - which is already set to on. Could Apple provide an update on when this bug will be finally squashed?

So, let me start here: Should I avoid 'cloning' directories in general with the copyfile function? No, quite the opposite. If you read the copyfile man page closely, you'll find that it's very careful to NEVER say that it clones directories. It either refers to cloning individual files or recursive cloning. Recursive cloning means using COPYFILE_CLONE on directories and is actually the standard behavior across all of our copy APIs (and the Finder). More specifically, COPYFILE_CLONE means that copy file calls clonefile for every possible individual file object and creates new objects for directories or anywhere it can't use clonefile. Note that this process is more sophisticated than it might seem, as it doesn't just use cloning within the same file system, but actually preserves clones across volumes (which is much trickier). copyfile() can also do standard copy all data copies on APFS but, to be honest, I've never come up with any good reason why you would do so, as it's basically the same as saying please m

What's the best way of being careful about this, or do you just mean by using the item replacement directory where possible? As far as I know, there are only two ways of getting a temp directory: Everything you've described sounds like you're on the right track. The big thing is just not making assumption about the relationship between directories (/tmp/ and home are on the same volume) or capabilities (home directories are ALWAYS on volumes that support cloning). The killer here is the long tail, as there are just SO many different edge cases. LibZip is much faster on a volume that supports cloning Interesting. Are you primarily editing the contents of the zip file (so you end up modifying the data inside, but don't really change it's overall size or structure)? Cloning is a huge help if you can clone the contents and then modify but if your modifications end up changing the fundamental contents, then I wouldn't expect the difference to be nearly as large. At large scale, this eventually devolves to

From your answer, I realise I was overlooking the obvious: after doing the work in the fast temp directory, I then need to create a second temp directory on the slower destination volume using URL(for: .itemReplacementDirectory…), copy the file across, and then use replaceItemAt from there. Sure, that makes sense. I think this is also one of those cases where the broader context of your app and user base is really a really important factor. Some apps (smaller documents, more consumer focused) should do their best to hide all of these details from the user, as they're not really useful/relevant and they just end up creating noise. Other apps (larger documents, more expert focused) benefit from making this visible to the user, as it lets them understand what's going on both to correct any problems (for example, space loss due to save failures) and take advantage of the data you have for them (for example, failure recovery). So any attempts to use that will continue to fail until the kernel (?) has finished with

and i pay 99usd yearly, the same amount as other big companies do and I dont get the same treatment?

Thanks for asking, Can you define big project? Is it larger than 100GB? Is it a certain number of files that causes the issue? What version of macOS are you using and with what hardware? And what provider are you using? (ChatGPT/Claude/Your own) Let me know, the more info the better. If I can reproduce this with a sample project, I would like to share this with the relevant engineering team.  Travis

[quote='878362022, Pushpak-Ambadkar123, /thread/816877?answerId=878362022#878362022, /profile/Pushpak-Ambadkar123'] it means I cannot distribute content filter solution on normal devices via App Store? [/quote] Yes. Well, it does depends on what you by “normal devices”. The Screen Time exception has no constraints on the device itself, but it does have constraints on the device’s user. Also note that this applies to all distribution channels, that is, App Store, TestFlight, Ad Hoc, and In-House (Enterprise). THat last one usually isn’t a big concern because the device is either supervised, or the device manager can configure your filter in per-app mode. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I hadn’t filed a bug report yet because I had assumed it was something I was doing wrong, given that using replaceItem and a temporary folder is presumably a common pattern. I’ll file a report tomorrow - I’m following the iCloud Drive profile instructions you linked to and am now waiting the 24 hours they say I need to wait before I can get the sysdiagnose. Once I have that, I’ll file the report along with a sample project. Perfect, thank you. ...using replaceItem and a temporary folder is presumably a common pattern I didn't get into it above, but there very likely are some nuances/details involved that are a contributing factor. For example, I suspect this doesn't happen if you start with a security-scoped bookmark, which you resolve to a bookmark before each save. I think NSDocument's default implementation also writes out a new file before each save, which means it's always starting with a new URL. That doesn't mean there's anything wrong with what you're doing, but that's probably why this isn't more wid