On Thu, Apr 17, 2008 at 6:10 AM, freeridecoding <[EMAIL PROTECTED]> wrote: > > Dear list! > > Using a MacFuse Filesystem implementation that does not implement any > of the methods concerning extended attributes (or even uses > auto_xattrs), MacFuse creates ._files containing those attributes.
I'm assuming since you are using a modified LoopBackFS that you are on 10.5. If that is the case, then MacFUSE does not create these ._ files. The Finder does; it sees that your file system does not support extended attributes and falls back to writing and reading AppleDouble files. On 10.5 MacFUSE may synthesize the extended attributes com.apple.FinderInfo and com.apple.ResourceFork for you if you implement one of "finderFlagsAtPath:, iconDataAtPath:, or URLOfWeblocAtPath:". From your description it sounds like this is not the case and is probably not what you want anyway. > While those files seem to work correctly when MacFuse accesses them, > they are not usable elsewhere. > > For instance: Running LoopBackFS I copy a textclipping file to the > mounted FS. If I doubleclick it on the FS volume, the clipping is > still ok. However, if I navigate to the /tmp directory where > LoopBackFS has actually created a textclipping file and > a ._textclipping file (which the Finder would usually combine > automatically), the textclipping cannot be opened anymore. (it is > empty as it would be if the appledouble file would be missing). I suspect that is because /tmp is HFS+, which supports extended attributes. When you try to open it on /tmp, it may be that the Finder doesn't even bother to look for a ._ file. Since it knows that HFS+ supports extended attributes and is getting back an ENOATTR when asking for com.apple.FinderInfo and com.apple.ResourceFork, it may decide that there is no resource fork. > > Comparing a MacFUSE created ._file with a version that is created by > "SplitForks" shows that both files are significantly different. The elements in these files can be ordered in any way so that might explain the difference you are seeing. I'm not familiar with SplitForks, so I don't have a firm explanation for this. > > Was it wrong to assume that the "._file" created by MacFUSE is a > standard appledouble file that would work copied on any filesystem > that does not support extended attributes or is this a bug? As I mentioned above, I think the ._file was created by the Finder. The ._file that would be synthesized by MacFUSE.framework on a 10.4 system does not support textclipping, so I doubt this was somehow created by MacFUSE.framework. ted > > Regards > Thomas > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
