[in]sufficient privileges

RADAR ID 4556357 Finder mishandles privileges from AFP share of Xsan volume Summary: Successfully copying a file with extended attributes off an AFP share of an Xsan volume, via Finder, requires the AFP client user to BOTH be the owner AND have Write access. Steps to Reproduce: Clean install of Mac OS X Server 10.4.6 and Xsan 1.3. On the server: Create an Xsan volume, connect to it as an Xsan client & share it via AFP. Set the share's owner/group to /staff and the permissions to rwxr-xr-x. Connect to the share from a workstation, using the account. Upload a file with extended atributes. Connect to the same share with another user account and double-click the file; it opens without error. Then drag the same file from the share to the Desktop; result is a warning dialog "The operation cannot be completed because you do not have sufficient privileges for some of the items." and the copy fails. Expected Results: Since the second user does have Read access, the copy should be allowed. Actual Results: See above. Regression: Am using Xserve G5 purchased in 2004/12 and Mac OS X Server 10.4.6 (fresh install on wiped RAID 1 of two ADMs in the Xserve) with Xsan 1.3 (fresh install and Xsan volume freshly created with 1.3 out of several XSR LUNs; XSRs all have latest firmware and QLogix SANBox 5200 also has latest firmware). Workstations tested: MacBook Pro w/ 10.4.6, PowerBook G4 w/ 10.4.3, G5 w/ 10.3.8 and others. Notes: - Accesing the share via SMB does NOT exhibit the problem; the file is copied. - Similarly via the command line (ex: scp); the file is copied. - "Privilege mapping" has no effect; the problem is exibited in either circumstance. (I watched the AFP debug messages via syslog, to confirm.) - ACLs are not a factor. (Confirmed via 'ls -aloe'; no ACLs show and are no available on Xsan voluems anyway, right?) - flags are not a factor. (Confirmed via 'ls -aloe'; none of the files show either uchg or schg flags.) - Confirmed that permissions on both pieces of the file ("" & "._" files) are the same, via 'ls -aloe'. - BTW: Here's another issue: The Finder appears to completely ignore the "Other/world" permissions. - NSUmask has no effect (as expected). - Renaming (at the command line, on the server) the "._" file that holds the extended attributes is enough to cause the copy (at the workstation) to succeed - without, of course, the extended attributes. Which is my case is critical because I'm sharing a historical archive of old files, many of which have resource forks with critical data. - It is understood that configuring a single machine as MDC, Xsan client and AFP server is sub-optimal, however the documentation does not forbid it, and budget, in this case, demands it. - To confirm: Probably also an issue with other nn-HFS volumes, such as UFS.