getxattr vs. ..namedfork
getxattr vs. ..namedfork
- Subject: getxattr vs. ..namedfork
- From: tim lindner <email@hidden>
- Date: Tue, 26 Jan 2010 08:02:40 -0800
In my shop I run a Windows file server that uses Services for
Macintosh. Recently I've been experiments using smbfs in order to get
long file name support. I turned on streams in nsmb.conf to have
access to existing resource forks and finder data. Overall everything
in working out as expected.
But I've run into a snag with rsync (Apple's stock version on 10.5.8).
I get errors on about 1 percent of the files with resource forks:
send_file failed to open "/tmp/.._filename.ABC123": Invalid Argument.
Looking over Apple's source to rsync I see it is using the copyfile()
api. I began writing toy programs to exercise copyfile() with my
specific problem files and kept getting the same errors.
So I downloaded the official rsync, applied the fileflags and crtimes
patches. This version of rsync doesn't use the copyfile() api, but
uses getxattrlist() and getxattr() calls. I started experimenting with
it. Getxattrlist() will correctly return the list of extended
attributes, and getxattr() can be used to get the size of every
extended attribute. But when the data is attempted to be copied, no
bytes are copied and errno is set to 22 (invalid argument).
I wrote a patch to detect this specific error, and use fopen(
"filename/..namedfork/rsrc", "r" ) and fread() to copy the resource
fork. It now copies the resource fork of the problem files.
I am not able to test against Mac OS X 10.6 to see if this problem has
been fixed. I don't want to file a bug report until I do.
I intend to look into the different code paths for getxattr() and
"..namedfork". Does anyone care to point me in the right direction?
--
tim lindner
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden