Dear list! It seems as if the Finder cannot create a file containing a larger amount of data inside the resourcefork on a FUSE volume.
The issue can be reproduced on an unaltered version of LoopBackFS. It consistently occurs when the xattr methods are removed (and Appledouble files are created). When copying files with resourceforks that are of small size (label colors, small textclippings...) everything works as expected. However, if you copy a file with a larger resourcefork using the Finder, the file ends up damaged on the Loop volume, independently if AppleDouble files are used or the xattr example implementation. As a "large" testfile I use a 1.4MB image clipping. The damaged clipping file on the target always shows a size of 128kb in my test cases. The problem consistently occurs on my own filesystem implementation which is quite different from the LoopBack FS case. The problem does NOT occur if the file is copied via cp. Then both creation of xattrs or appledouble files works as expected. If I understand all correctly, this would mean that some Finder checking would lead to an interruption in copying the extended attributes. I have tried to track what is different from the usual file creation and writing but I do not see anything special. I am not sure if the Finder probably checks parts of the xattrs during writing parts of the data, but I do not see any room left to satisfy the Finder on the implementation side. Is there any way satisfy the finder so the resourcefork data is preserved on the FUSE volume? Is there any known issue I have overlooked? Thanks for your time, Thomas B --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
