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
Topic:
App & System Services
SubTopic:
Core OS
Tags: