I'm confused. Earlier you wrote the resource fork should only exist on compressed files, and cp DOES copy those but in your last reply Use the Finder to do the copy, not cp and cp decompressed the file, which ended up stripping the xattrs This doesn't make sense to me... I tried creating a file with a resource fork as you suggested, but again I wasn't able to reproduce the "Result too large" issue. The file, an empty .txt file on my Mac (macOS 26.2) which I added a 14.1 MB resource fork to, now displays as 14’136’946 bytes (14.1 MB on disk) in the Finder. Copying it to the FAT volume (inserted in my router and connected via SMB to my Mac) with the Finder, the cp command, or the test app I showed at the beginning which uses copyfile: they all worked, and the Finder displays the destination file as 14.1 MB. The only error I got was when trying to add the resource fork to an empty file created on the SMB volume: cat: stdout: Operation not permitted So I copied the file with the resource fork on my Mac to the SMB volume in the Finder, then copied the file on the SMB volume back to my Mac with each of the 3 methods above, and they all produced the same result: a Zero bytes file without a resource fork (confirmed by ls -l@). I don't know why this is the case. I'm wondering: does this mean The test above was done with both machines running macOS 26.3 and the underlying source volume being APFS that I can only reproduce it when at the other end of the SMB connection there is a Mac, or if the volume at the other end is formatted APFS? Note: I repeatedly used the ls -l@ command to check whether the various file copies had a resource fork. Randomly, I got weird results. The correct one would be: com.apple.ResourceFork 14136946 com.apple.quarantine 23 but sometimes I got a smaller resource fork com.apple.ResourceFork 11534336 com.apple.quarantine 23 or com.apple.ResourceFork -1 com.apple.quarantine 23 or even -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 Please forgive me if I say that these resource forks are already giving me headaches...

I ran the following commands in Terminal: cp /System/Library/CoreServices/Finder.app/Contents/Resources/Invitation.aiff ~/Downloads/Invitation.aiff xattr ~/Downloads/Invitation.aiff chflags -v 0 ~/Downloads/Invitation.aiff xattr ~/Downloads/Invitation.aiff but the output of each of these commands was empty, so again it seems that even with the chflags -v 0 Invitation.aiff command no extended attributes are revealed on that file. I tried copying the same System/Library/CoreServices/Finder.app/Contents/Resources/Invitation.aiff file to a FAT volume connected via SMB, and the results are the same. I'm afraid we'll never know how that file (and hundreds others) got to the SMB volume. The user told me they're currently unable to reproduce the issue and are tired of running experiments, so I guess that's it for now... until I'll hear from the next user having the same issue. I have lost count of how many users have already contacted me about the exact same issue and how many days I've already spent trying to debug it with their help, so a fix would be truly appreciated. I was trying to replicate it on my Mac in the hope of understanding it better and so that I could suggest a workaround to users who might contact me in the future.

[quote='874603022, DTS Engineer, /thread/814076?answerId=874603022#874603022'] Copying a file with a small resource fork (~56 Kb) failed [/quote] Which file did you copy? I assume the one you reported in the code block afterwards /System/Library/CoreServices/Finder.app/Contents/Resources/Invitation.aiff but when executing the xattr command on that file I don't get any output, i.e. it seems that it has no extended attributes.

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 = open(path, O_RDWR) if f < 0 { throw NSError(domain: NSPOSIXErrorDomain, code: Int(errno)) } var buf = UnsafeMutableRawPointer.allocate(byteCount: 4, alignment: 4) var r = fsetxattr(f, "asdf", &buf, 4, 0, 0) if r != 0 { throw NSError(domain: NSPOSIXErrorDomain, code: Int(errno)) } r = close(f) if r != 0 { throw NSError(domain: NSPOSIXErrorDomain, code: Int(errno)) } Output of ls -l@ file: asdf 4 com.apple.FinderInfo 32 com.apple.ResourceFork 34669586 com.apple.quarantine 57

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 57 Could com.apple.ResourceFork be the culprit? It doesn't seem to be exceedingly large to me, but maybe zipping a file doesn't correctly preserve extended attributes. Should I ask the user to run this command on their Mac? I also found this Stackoverflow post from 13 years ago which sounds like it could be the same issue, although they were trying to copy the extended attributes with xattr, not with filecopy: https://stackoverflow.com/questions/13533796/copy-mac-com-apple-resourcefork-extended-attribute-causing-argument-list-too-lo I created FB21805212.

Ok, so just to make things clear, is it expected that whenever I want to change the SpriteKit scene and also avoid concurrently accessing objects that may be changed in the current thread, I have to queue the SpriteKit changes by capturing all the needed state? It's just surprising to me that this is needed when SpriteKit is used as an overlay in SceneKit, but when running SpriteKit alone, it doesn't seem to be needed. I filed at least one feedback recently about crashes happening only when SpriteKit is used as SCNView.overlaySKScene. Is it expected that one has to use this... boilerplate code when embedded in SceneKit? Couldn't one do without it by simply overlaying a SkView on top of SCNView? class SceneController { private var shapeNode: SKShapeNode! func main() { let shapePath = CGPath(rect: CGRect(x: 0, y: 0, width: 10, height: 10), transform: nil) GameViewController.shared.updateSpriteKit { [shapeNode, shapePath] in shapeNode!.path = shapePath shapeNode!.fillColor = .systemRed } } } class GameViewController: NSObject, SKSceneDelegate { static let shared = GameViewController() private var skQueue = (queue: DispatchQueue(label: "skQueue", qos: .userInteractive), updates: [() -> Void]()) override func loadView() { let overlay = SKScene() overlay.delegate = self } func updateSpriteKit(_ block: @escaping () -> Void) { skQueue.queue.async { [self] in skQueue.updates.append(block) } } func update(_ currentTime: TimeInterval, for scene: SKScene) { skQueue.queue.sync { for block in skQueue.updates { block() } skQueue.updates.removeAll() } } }

Thanks for your help. Updating SpriteKit from multiple threads is what I suspected too, but the crash shows only one thread accessing SpriteKit in that moment. Although the code in thread 1 does in fact update the path and fillColor properties of a SKShapeNode 6 lines before the one mentioned in the crash report. Could this still be the issue?

I figured it out. It seems that when all English strings are provided via NSLocalizedString's value argument, en.lproj is not created. In fact, when mixing localized strings with and without default values, only those that have no default value are included in the final app's en.lproj/Localizable.strings. Still, when running the app, the default value is correctly presented, so I guess since it's not in the strings file it is hard-coded in the executable. Maybe I'm not supposed to use the value argument this way? Should I instead cut all the default values and insert them manually in the string catalog? I was already considering to move all English values for my other projects from the string catalog to the source code so that I directly know what a localized string's contents are, but I'm happy now I didn't do that yet. I created FB21733395.

The rows in the English column all contain black text, which is the text passed as the value argument to NSLocalizedString(_:value:comment:). The app also runs in English if I select it in the Xcode scheme editor.

The submitted app does indeed miss a en.lproj folder. How do I know if I'm using a string catalog? Isn't having Localizable.xcstrings enough? These are the project settings filtered by "catalog", they are the same for the other projects that show the correct languages on the App Store: The target build settings filtered by "catalog":

Thanks, that works. If not for this, what is UIAction.Identifier.pasteAndMatchStyle used for?

I created FB9832605 in January 2022 titled "Dragging folder onto Simulator causes permission error", but after answering some initial questions it never went forward. Though it displays "Recent Similar Reports: Less than 10".

Recently two users of my apps reported the same issue happening on macOS 15.7.2. Will it be fixed on both macOS 26 and 15?

Another user of my apps just reported the same issue again on macOS 15.7.2.

I don't have a bug number. I only got an email from a user who said they have this issue on macOS 15.7.2, that's all.