On 8/15/07, Amit Singh <[EMAIL PROTECTED]> wrote: > The user-space library does argument filtering, so you have to add new > arguments to lib/mount_bsd.c in there too. Yes, it's a tad painful. I > think I already added 'noautoextattr' to the 10.5 MacFUSE tree.
Ah, yes, thanks. It works fine now. > Actually, the 'noautoextattr' option does work in 10.5. In particular, > if I don't "short circuit" com.apple.FinderInfo and > com.apple.ResourceFork in the kernel, and the user-space file system > handles these correctly, then it can use these to implement per-file > custom icons. The 32-byte finder info data would need to have the "has > custom icon" bit set and the resource fork data would need to be the > icon file. > > I haven't test, or even implemented this for 10.4 yet--my suspicion is > that Finder won't be happy still, but feel free to test and verify one > way or another. I can verify that it doesn't work in Finder in 10.4. (This is not surprising because listxattr is never even called despite being exempt from short-circuiting; I tried implementing getxattr for com.apple.FinderInfo and com.apple.ResourceFork using noautoextattr just in case the Finder is doing something strange, but it still doesn't work.) I am hoping that you are verifying that Finder in 10.5 does honour resource forks and finder info through extended attributes rather than just through AppleDouble files, but you have used quite a lot of the conditional tense at the end there! I have just implemented a version of HELLOWORLDFS which takes an extra option "icns_file=%s". If a file exists at the given pathname, it bundles it up as a resource fork containing an icns resource with id -16455, and serves that when asked for xattr com.apple.ResourceFork, as well as serving an appropriate com.apple.FinderInfo with the kHasCustomIcon finder flag set. I haven't yet written the bit that parcels that up as ._hello.txt, so it doesn't work on 10.4. Would you like to try it on 10.5? I was thinking about writing a standard option "manage_dotunderscorefiles" which would basically serve dot-underscore files for any files that didn't have one (and weren't one themselves) containing the results of calls to getxattr. But if Leopard handles this correctly it's less important to do so. Going back to noautoextattr, would it be possible to create a sort of half-way house? That is to say, if listxattr returns com.apple.FinderInfo / ResourceFork / system.Security, they're handled using getxattr / setxattr, otherwise they're handled using dot-underscore files. Hamish --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "macfuse-devel" 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-devel?hl=en -~----------~----~----~----~------~----~------~--~---
