Yes, com.apple.{FinderInfo, ResourceFork} handling through *xattr()
works in 10.5 Finder.Also, the behavior in 10.5 MacFUSE is already like what you're asking for. If your file system wants one or more attributes to be handled through ._ files, then it should return ENOTSUP for the xattr calls for such attributes. Then, the kernel will use the ._ codepath as fallback. I will actually drop the 'noautoextattr' argument. MacFUSE will do the right thing: if a file system doesn't even implement the xattr functions, then ENOTSUP will be implied. Amit On Aug 15, 5:20 pm, "Hamish Allan" <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
