EncFS on MacFuse problem. getxattr return code.

[kensmosis]

I had been having problem with saving files on an EncFS volume on a Mac (MacFuse) using certain programs. In the course of discussing this with MacFuse developer Amit Singh, he took a look at the source code for encfs and identified the following issue. The thread is http://groups.google.com/group/macfuse-devel/browse_thread/thread/e3b5c3fe31f44267?hl=en

In Amit's words:

"I took a look at the encfs source (version 1.4.2--perhaps older
versions are similar).
Your issue is occurring because the implementation of xattr functions
(particularly getxattr() and listxattr()) isn't correct in encfs.
Unlike most other system calls, these functions don't return 0 on
success--they return the size of the extended attribute and the size
of the extended attribute list, respectively. encfs is returning 0 for
both, which causes the caller to conclude that there is no xattr data.
When this happens right after the Finder tried to set an xattr (which
did succeed), the Finder goes into fits of frenzy when it can't read
the data it recently wrote.
The fix is to make encfs return correctly from these functions.
If encfs didn't implement xattr functions at all, you wouldn't see
this problem because the kernel would then resort to using ._ files
for holding extended attribute data. You can use the "-oauto_xattr"
mount-time option to make MacFUSE force ._ files (the option causes
MacFUSE to ignore the fact that the user-space file system has
implemented xattr functions). Of course, the downside is that your
xattrs will go to ._ files, but give it a shot to make sure that it
indeed fixes your file saving issues.
There's another thing encfs would have to do to implement xattr
functions correctly (for Mac OS X). In MacFUSE 1.7+, the getxattr()
and setxattr() callbacks take an additional argument: the position
(see the header file for the prototypes). This is required for proper
function of xattrs on Mac OS X because in the special case of resource
forks, the kernel can use the position argument to request data at an
offset within the extended attribute. This way, resource forks can be
"large" (for "normal" extended attributes, their data can't be
streamed or broken into chunks--it's all read at once in a single
getxattr() call.)
You should report this to the encfs developer.
Amit "

I hope this is helpful.

Cheers,
Ken Halpern