I'm implementing a FUSE file system and would like to make it available via MacFUSE. I'm using the 2.0.3 MacFUSE binary distribution on a Leopard (10.5.8) dev machine and am hoping to use the file system on Leopard and Snow Leopard machines as well as other non-Mac boxen.
At this point, the system works well for Unix terminal commands like ls, mkdir, etc. FInder can browse the file system's directories and launch apps like TextEdit on selected files. TextEdit can save edits back into files and I can drag-n-drop files from the FUSE file system into a Mac's HFS+ directory. My problem is in attempting to drag-n- drop (or copy-n-paste) files from the HFS+ file system into the FUSE file system. Drag-n-drop onto FUSE generally fails with stickup warnings about admin passwords, can't write everything, etc. and, after creating and writing a dropped file (and its ._ double) followed by a bunch of getattr calls on it (and on it's double) and on the "._." double, the dropped files are unlinked. My FUSE file system doesn't yet implement xattr operations and I believe drag-n-drop is failing and FInder is unlinking the copies because it wasn't able to save com.apple.FinderInfo xattrs and it's being atomic. So far, I've haven't found a combination of default_permissions, defer_permissions, noappledouble and noapplexattr options (or absence of all of them) that works for me. If noapplexattr, then both forks are always unlinked. If noappledouble, the data fork remains on Leopard but is zero length on Snow Leopard. The file system's access and getattr operations appear to return correct stat structs for the dropped files. Can you suggest something I'm missing that can be configured with MacFUSE options? My preference would be to avoid the apple double clutter since that's Mac specific and the ._ files seem to be at least 4KB and each .DS_Store file at least 6KB. I'd thought that xattrs would be written to double files if the file system didn't support xattrs and I was willing to take the double files size hit for the near term but that may be incorrect. I think it may be necessary to implement the xattr operations for my file system. A trial hack at that which honors just the com.apple.FinderInfo xattr did allow the data fork to be dropped (although still with an error - 36 stickup). In this case there were no ._ double files created although there were many getattr( ) calls apparently probing for one. Is fully implementing the xattr operations necessary to support Finder's drag-n-drop? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "MacFUSE" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/macfuse?hl=en -~----------~----~----~----~------~----~------~--~---
