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
-~----------~----~----~----~------~----~------~--~---

Reply via email to