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 On Jul 7, 9:41 pm, Kensmosis <[EMAIL PROTECTED]> wrote: > Hi Amit, > > Thanks for the clarification about sshfs -v. Your kextstat command > seems to show that 1.7.1 is being dynamically loaded, though. Sorry > if my language is imprecise; I'm relatively new to MacOS (I just got > your book, so hopefully I'll have a better understanding soon). > > Cheers, > Ken > > On Jul 7, 6:18 pm, Amit Singh <[EMAIL PROTECTED]> wrote: > > > On Jul 7, 2:43 pm, Kensmosis <[EMAIL PROTECTED]> wrote: > > > > Hi Amit, > > > > Exactly; I was looking at sshfs -v. > > > That's not the "active kernel extension". sshfs is merely telling you > > (through the MacFUSE library) the kernel interface version the library > > wants. This is passive information--not active (that is, it's not > > looking at any kernel extensions that might be loaded.) > > > Amit --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "macfuse-devel" group. To post to this group, send email to macfuse-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/macfuse-devel?hl=en -~----------~----~----~----~------~----~------~--~---
