On Oct 27, 2:52 pm, "Sam Moffatt" <[EMAIL PROTECTED]> wrote: > As a side note, Leopard introduced a new API called "copyfile" (man > copyfile) that is designed to handle fork and EA copying better which > is why you're seeing Leopard Finder behave better than Tiger Finder.
That's not quite correct. First off, copyfile() is there in Tiger as well. It's just not documented or supported very well. Secondly, that's not why the Leopard Finder behaves better than the Tiger Finder. I've talked about this before on this forum: == Another example: MacFUSE fully supports extended attributes, both on Tiger and Leopard. This is great for file systems that wish to natively support extended attributes: that way, they won't cause generation of "._" files; things like Finder info, resource forks, and even ACLs can be natively handled by file systems. However, on Tiger, no matter what the file system does, when you go through the Finder, you're back to using "._" files. If you go through the command line, things work correctly. This is because on Tiger, the Carbon File Manager can directly manipulate "._" files (so does the kernel), but the File Manager uses a bizarre test to determine if a volume supports native xattrs. It checks if the volumesupports "volfs". If it does (MacFUSE doesn't, and shouldn't have to), it concludes that it must support xattrs too. == So, the real reason is that on Tiger, the Finder (the File Manager) refuses to believe that the volume in question can support extended attributes. Amit --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "MacFUSE" 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?hl=en -~----------~----~----~----~------~----~------~--~---
