1. MacFUSE _never_ creates ._ files--the kernel does. It's the kernel that determines whether a volume doesn't support extended attributes, and if so, it falls back to an alternate code path that creates/ deletes/reads/writes ._ files. Of course, a file system can "synthesize" ._ files, just like any other type of files.
2. If by "usable elsewhere" your expectation is that on HFS+ (the /tmp in your example) you should be able to see the "automatically combined" version, that's not how it works on Mac OS X. HFS+ supports native extended attributes. Just because you happen to have a ._ file doesn't mean the kernel will try to "combine" it with the "main" file. The kernel will not even look for it on HFS+. 3. Don't expect ._ files to be byte-by-byte identical for what you perceive as identical operations. 4. To correctly test "usable elsewhere", try copying from a MacFUSE volume to HFS+ (don't just go an look at where LoopBackFS is storing the "real" files). Alternatively, try copying from a MacFUSE volume to another volume (one that doesn't natively support extended attributes-- like an MS-DOS volume.) Amit On Apr 17, 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. > 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). > > Comparing a MacFUSE created ._file with a version that is created by > "SplitForks" shows that both files are significantly different. > > 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? > > 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 -~----------~----~----~----~------~----~------~--~---