filecopy fails with errno 34 "Result too large" when copying from NAS

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.

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.

Both the app user and QNAP are willing to help, but at this point I'm also unsure how to proceed. Can someone at Apple say anything about this? Is this something QNAP should solve, or is this a bug in macOS?

P.S.: I've had users in the past who reported the same issue with other brands, mostly Synology.

import Cocoa

@main
class AppDelegate: NSObject, NSApplicationDelegate {

    func applicationDidFinishLaunching(_ aNotification: Notification) {
        let openPanel = NSOpenPanel()
        openPanel.canChooseDirectories = true
        openPanel.runModal()
        let source = openPanel.urls[0]
        
        openPanel.canChooseFiles = false
        openPanel.runModal()
        let destination = openPanel.urls[0]
        
        do {
            try copyFile(from: source, to: destination.appendingPathComponent(source.lastPathComponent, isDirectory: false))
        } catch {
            NSAlert(error: error).runModal()
        }
        
        NSApp.terminate(nil)
    }
    
    private func copyFile(from source: URL, to destination: URL) throws {
        if try source.resourceValues(forKeys: [.isDirectoryKey]).isDirectory == true {
            try FileManager.default.createDirectory(at: destination, withIntermediateDirectories: false)
            for source in try FileManager.default.contentsOfDirectory(at: source, includingPropertiesForKeys: nil) {
                try copyFile(from: source, to: destination.appendingPathComponent(source.lastPathComponent, isDirectory: false))
            }
        } else {
            try copyRegularFile(from: source, to: destination)
        }
    }
    
    private func copyRegularFile(from source: URL, to destination: URL) throws {
        let state = copyfile_state_alloc()
        defer {
            copyfile_state_free(state)
        }
        var bsize = UInt32(16_777_216)
        if copyfile_state_set(state, UInt32(COPYFILE_STATE_BSIZE), &bsize) != 0 {
            throw NSError(domain: NSPOSIXErrorDomain, code: Int(errno))
        } else if copyfile_state_set(state, UInt32(COPYFILE_STATE_STATUS_CB), unsafeBitCast(copyfileCallback, to: UnsafeRawPointer.self)) != 0 {
            throw NSError(domain: NSPOSIXErrorDomain, code: Int(errno))
        } else if copyfile(source.path, destination.path, state, copyfile_flags_t(COPYFILE_DATA | COPYFILE_SECURITY | COPYFILE_NOFOLLOW | COPYFILE_EXCL | COPYFILE_XATTR)) != 0 {
            throw NSError(domain: NSPOSIXErrorDomain, code: Int(errno))
        }
    }

    private let copyfileCallback: copyfile_callback_t = { what, stage, state, src, dst, ctx in
        if what == COPYFILE_COPY_DATA {
            if stage == COPYFILE_ERR {
                return COPYFILE_QUIT
            }
        }
        return COPYFILE_CONTINUE
    }

}

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 suggestions:

  1. What do you "know" about the file? Is it a particular file or all copies from that source? If it's a particular file, what makes it different than the other files? This can be difficult to investigate without direct access to the file system, but the basic answer here is that "something" about that file makes it different and finding that difference generally explains the entire problem. The issue I mentioned about is tied to very large xattr copying (particularly the resource fork), so it shouldn't be happening with most "normal" file content.

  2. Try doing the same copy with cp. If cp works, then that opens up a new investigation path. "cp" is open source and, while the code is somewhat complex, it's straightforward enough that it's reasonably straightforward to compare the two implementations. This then becomes a matter of simply reworking your implementation to match cp's.

  3. If cp fails, that shifts the problem out of your code and onto the file system side. It also means that, assuming that the Finder works fine, the problem is specific to the "copyfile" copy stack (which the Finder doesn't actually use). I'm not sure I'd really "suggest" it, but that also opens up another potential workaround, which would be to retry the failing copy with the Carbon File Manager, as described here. I can't guarantee that will work, but I strongly suspect it will.

Finally, if you haven't already, please file a bug on this and post the bug number back here.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

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.

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:

  1. 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.

  2. 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 file gets created and its "data" was copied, but then failed during the resource fork copy operation.

Could com.apple.ResourceFork be the culprit?

Sort of, and this is making me feel like an old man...

So, when HFS was originally introduced as part of System 2.1 in 1985, one of its innovations was the introduction of "dual fork" files. Any file could actually be made up of two different "forks". The "data fork", which is what contained a file’s normal content, and the "resource fork", which contained structure data accessed through a special API called the "resource manager".

For most of Classic MacOS's history, the resource fork and resource manager were a foundational part of how the system and apps operated. Most notably, apps heavily relied on the resource fork for storing their own "app data". The modern bundled app architecture was basically created to replace the resource manager.

Moving forward in time (1990s->2000s), two different things were basically happening at the same time:

(1)
There were widespread and very geeky debates about how awesome/awful multi-fork file systems were. The majority (Windows/Unix) argument was that "a file" consisted only of a single data stream and the Classic MacOS was crazy.

(2)
File system designers came decided that multi-fork file systems were a FABULOUS idea. The issue here is that, historically, file systems were basically designed and evolved like this:

  • A group sits down and decides exactly what data belongs "in the file system".

  • The file system designer goes and designs a set of on-disk structures that hold that data.

  • The file system ships; everyone is happy.

  • Sometime later, someone comes to the file system architect and says "I've got this great idea and all I need you to do is store this extra..."

  • The designer finds some nook and/or cranny to store said data that doesn't break anything.

  • This process repeats until the file system has become sufficiently twisted up that the designer is forced to start over.

File system designers are not fools, so, having fallen for this trick a few times, they refused to be fooled again... and created the "Extended Attribute" ("xattrs"). That is, they created a mechanism that allowed a file to be made up of multiple independent streams so that the higher-level system could attach whatever it wanted to the file without bothering the file system designer again.

And, yes, the timing of these two trends was EXACTLY as ironic as it sounds. That is, file system designers were widely implementing multi-fork file systems at EXACTLY the same time the rest of world was loudly yelling about how silly they were.

With all that context...

Could com.apple.ResourceFork be the culprit?

Yes, but only in an indirect sense. Most extended attributes are fairly small (bytes or kb), but the resource fork is the exception. I don't know what its formal limits really are; 20MB-50MB was pretty common, and the Resource Manager was robust enough that DTS had a semi-famous "The Resource Manager is not a Database" technote. In this case, that means that any problem with copying large xattrs is going to fail with the resource fork, since it tends to be the biggest.

Shifting to the current issue:

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:

I don't know what the file itself actually was, but I suspect this was actually a file system compressed file. This thread has more background on this, but many years ago (~2012), we introduced a mechanism that allowed the file system to "invisibly" compress specific files, and that mechanism reused the resource fork.

That's also why:

From what the user told me, the issue only happens with some files.

File system compression is largely invisible to the user, though you can see signs of it if you know what you're looking for. For example, if you "Get Info" on a directory like "/System/Library/CoreServices”, you'll find that its logical size is BIGGER (~200 MB) than its physical size:

Size: 867,557,303 bytes (616.8 MB on disk) for 719 items

Those differences accumulate, so the size gap on /System/Library is typically a savings of ~12+ GB.

Should I ask the user to run this command on their Mac?

The big thing to test here is moving the file with "cp". If cp fails, then I'm pretty confident that the problem is the bug I mentioned before. You can also have them do a "Get Info" on the file, as any compressed file will have the same logical size discrepancy.

although they were trying to copy the extended attributes with xattr, not with filecopy:

If you look at its implementation, xattr is doing a fairly naive single call to fsetxattr() which tries to write everything in a single call. That works fine for most attributes (because they're tiny) but will fail with large attributes, particularly the resource fork. copyfile is doing the right thing here (which is why it works fine at other locations) but smb is not.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

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

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 "out" of the system. You can actually see the copyfile check for this here, but the summary is that we only preserve compression if/when the filesystem specifically declares support for that, which I wouldn't expect any NAS box to do. This also applies to copying our own compressed files across SMB (we con’t copy them), so I’m not sure how he “got” the file he’s having issue with on to the SMB server.

...calling copyfile as in the code I posted in my first post still works,

There are a large number of variables here, but I was able to reproduce the issue fairly easily with two Macs. Copying a file with a small resource fork (~56 Kb) failed with:

cp: <source>: could not copy extended attributes to (<dest>): Result too large

HOWEVER, interestingly, the issue is a bit more complicated than that. As I noted earlier, the resource fork should only exist on compressed files, and cp DOES copy those. More specifically, I start on the source with a compressed file like:

/System/Library/CoreServices/Finder.app/Contents/Resources/Invitation.aiff

Get Info:
 Size: 56,090 bytes (45 KB on disk)

Copy that over to a test location (on the remote machine) and duplicate the file so you end up with 2 files:

Invitation.aiff
Invitation2.aiff

Then run this command to intentionally break compression on Invitation2.aiff:

chflags -v 0 Invitation2.aiff

Resulting in:
xattr Invitation2.aiff
com.apple.ResourceFork
com.apple.decmpfs

Now, switching to the destination machine and using cp to copy both files results in:

Invitation.aiff -> File copied uncompressed

Get Info: 
 Size: 56,090 bytes (57 KB on disk)

Invitation2.aiff -> Failure
cp: TestDat/Invitation2.aiff: could not copy extended attributes to <dest>Invitation2.aiff: Result too large

I also did some testing with larger files and they behaved the same, though the specific error message wasn't printed (cp failed silently instead, not sure why).

...when the destination is on a FAT volume connected via SMB.

Keep in mind that the edge cases here get really messy. On top of everything else, the system specifically includes support for storing resource forks on file systems (like FAT) which don't have ANY multi-fork support. This support involves using a separate file for storage and, adding to the fun, most of this support is actually in the VFS layer (above the specific filesystem, like SMB). At that point, you're headed down a completely different set of code paths, basically unrelated to the more "modern" logic flow.

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.

I'm not sure what you mean here. This code worked fine for me:

//
//  main.swift
//  fsetxattr_test
//
//  Created by Kevin Elliott on 2/2/26.
//

import Foundation

let path = "/Volumes/HomeBase/Test_Data/testfile"

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 = fsetxattr(f, "com.apple.ResourceFork", &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))
}

Result:

xattr testfile
asdf
com.apple.ResourceFork

Note that the details here can/will vary depending on the volume and the specific file. In the case here, I created the file using "touch" first.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Copying a file with a small resource fork (~56 Kb) failed

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.

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.

Yes, that's because xattr is lying. More specifically, when a file is compressed, we set a file flag ("UF_COMPRESSED") that marks that file as compressed. Among other things, that flag hides the true xattr configuration from other parts of the system.

In any case, that's why I ran this command above:

chflags -v 0 Invitation2.aiff

Setting the file flags to "0" implicitly clears the "UF_COMPRESSED" flag, which will then cause xattr to show its true configuration:

Resulting in:
xattr Invitation2.aiff
com.apple.ResourceFork
com.apple.decmpfs

In any case, summarizing the overall situation:

  • There is definitely an issue with copying large resource fork data across SMB.

  • At this point, I'd expect resource fork usage to be fairly limited, and the most common use case (compressed files) works fine, as the file ends up being uncompressed during copying.

Jumping to here:

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.

Do you know what kind of file this was/is and how it "got" to the SMB volume? It doesn't really change anything about the bug itself, but the main reason the bug here isn't more common/visible is that we're fairly actively avoiding resource fork usage, and apps shouldn't/can't really be using it either. Honestly, I can't really think of any way for the resource fork data to "reach" a NAS device unless you're dealing with really old data (which still has valid "native" data) or there's a tool involved that's basically "broken".

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

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.

I ran the following commands in Terminal:

Use the Finder to do the copy, not cp. More to the point, jumping back to what I posted in earlier, this pattern (logical size > physical size) is the easy way to check if you're looking at a compressed file:

Get Info:
 Size: 56,090 bytes (45 KB on disk)

Similarly:

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.

The system is ACTIVELY trying to prevent compressed files from "leaking" out of its control. Basically, it will only preserve compression when you're doing local copies to file systems that specifically support it. That means APFS-> APFS and MAYBE HFS+. Note that this does NOT include smb. If you start with a compressed file and copy it across smb, the system ends up decompressing it as part of the copy.

That's almost certainly what happened here:

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.

That is, cp decompressed the file, which ended up stripping the xattrs. Make sure you've got a compressed file at a writable location before you bother trying to test anything.

I was trying to replicate it on my Mac in the hope of understanding it better and

So, the compressed file side of this is somewhat of a distraction. If you simply want to replicate the issue directly, you can do the following:

  • Mount the smb volume.

  • Create a file with a resource fork by doing:

touch <new file>
cat <large input file> > <new file>/..namedfork/rsrc
  • Copy with Finder-> file copies fine.

  • Copy with cp-> Resource for fails to copy.

Note that the critical factor here is the characteristics of the smb volume/server. The test above was done with both machines running macOS 26.3 and the underlying source volume being APFS (the simplest configuration).

so that I could suggest a workaround to users who might contact me in the future.

In terms of a workaround, I'm pretty confident that the Carbon File Manager code I posted above will copy these files fine. You should confirm that for yourself, but assuming I'm correct, it wouldn't be that difficult to just continue with copyfile, retrying any file that has an error with the Carbon File Manager code.

On the user side, the obvious option would be to copy with the Finder. Beyond that, I think it really depends on what the file actually "is" and how it got there. If these are actually compressed files, then the problem isn't simply copying them but is also "using" them on the other side. If the resource fork is visible, that means "UF_COMPRESSED" has been stripped, which basically "breaks" the file, and fixing that is a separate conversation. If they're not compressed... then I'd like to figure out what these files are and how/why they have a resource fork.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

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...

This doesn't make sense to me...

In brief, compressed files were implemented by:

  • Compressing the file’s contents.
  • Storing that data in the resource fork.
  • Adding a file flag ("UF_COMPRESSED") which tells the VFS layer "this file is compressed".

The VFS layer then checks for files with the "UF_COMPRESSED" flag. When it sees that flag:

  • It hides the resource fork from most/some API layers.

  • When the file is opened, it decompresses the contents returning them as if it were a "normal" file.

That last point means that a copy engine that's "unaware" that a file is compressed:

cp decompressed the file, which ended up stripping the xattrs

…ends up automatically decompressing it.

Reordering things a bit:

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?

Yes and no. The problem here is that the full range of "SMB servers" is EXTREMELY large and diverse. Similarly, you can have cases where you get exactly the same behavior for TOTALLY different reasons. Unless you can control for the server, that makes it very difficult to differentiate between:

  • Something failed because the client did the wrong thing.

vs

  • Something failed because the server did the wrong thing.

That's a particular issue here because, historically, one of the biggest issues with 3rd party SMB servers is that they didn't handle our metadata properly... particularly the resource fork. As a side note here, using a Mac as the server doesn't actually make it any clearer whether a problem is server or client side. What it does is make sure that any failure... is still our problem, since both components are "ours".

Adding to the fun, are configurations like this:

Copying it to the FAT volume (inserted in my router and connected via SMB to my Mac)

FAT has no support whatsoever for things like resource forks or extended attributes. As far as FAT is concerned, a file is a single stream of bytes with a name attached and a date or two. Historically, this was such a huge problem that we invented multiple file formats ("AppleSingle" and "AppleDouble") which were then integrated into Mac OS X.

So, now you have two different layers interacting to create failures and, even better, you can't necessarily trust what you see in tools like Terminal, as those same compatibility layers conceal the "truth" from you.

That leads to here:

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-byte file without a resource fork (confirmed by ls -l@). I don't know why this is the case.

The problem here is that you HAVE reproduced the bug. Strictly speaking, you should use "cp -p" (to ensure it "should" copy the resource fork), however, that failure to properly copy the resource fork IS a bug. The problem is that if the Finder is ALSO failing, then that's a different bug and, given the other testing you've heard about, it's almost certainly a bug in the SMB server, NOT the SMB client.

Similarly:

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:

...there's no good way to know if that's the client or the server.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

filecopy fails with errno 34 "Result too large" when copying from NAS
 
 
Q