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

Which Mac OS X version are we talking about? That's *really* important
information when talking about xattrs and MacFUSE, you know.

Amit

On May 7, 2:04 pm, freeridecoding <t...@freeridecoding.com> wrote:

Sorry for the lack of details: The described issue affects MacOSX
10.5.2 on an Intel machine.
I am using the latest MacFUSE version (1.5).

If you look at the man pages for getxattr() and setxattr(), you'll see
a non-standard "position" argument. This argument is meant for
optional use when accessing resource forks as xattrs. The Finder
insists on using the position argument--it splits resource fork I/O
into 128K chunks. MacFUSE can handle much larger chunks, but that
doesn't help here.

The current release of MacFUSE does not support the position argument.

I've added support for this in the source tree. Ted will hopefully
soon extend the Objective-C API to handle position. Everything should
be in the next MacFUSE release.

Amit

I've modified the Objective-C API to support the position argument for
setExtendedAttribute and valueOfExtendedAttribute.  The new versions
that your delegate should implement look like:

- (NSData *)valueOfExtendedAttribute:(NSString *)name
                    ofItemAtPath:(NSString *)path
                            position:(off_t)position
                                 error:(NSError **)error;
- (BOOL)setExtendedAttribute:(NSString *)name
                ofItemAtPath:(NSString *)path
                           value:(NSData *)value
                       position:(off_t)position
                        options:(int)options
                            error:(NSError **)error;

Please also note the argument name change from flags to options.

GMUserFileSystem will prefer these new selectors if your delegate
implements them.  Otherwise it will call the old selector for now.
Eventually I'll probably remove support for the calling the deprecated
selectors.

I've also updated LoopbackFS and confirmed that I can copy in a file
with a ResourceFork that is larger than 128K.  You can look at the
head of the source tree to see the updated API and how it is used.

ted

Hi!

Thanks for your quick replies.
I can confirm that using the new LoopBack example and the new MacFUSE
version
now fixes the issue - when xattrs are supported in the implementing
fs.

However - If xattr implementation methods are removed (and AppleDouble
files should be created),
the created AppleDouble file is still damaged and of size 128kb.
Unfortunately for me I need to solve it in that way because I need the
AppleDouble files.

What I have learned from your comments to my questions in another
thread,
if the fs does not implement xattrs, the kernel itself initiates the
creation of AppleDouble files.
In my understanding this would mean that the kernel subsequently
calles the filesystems open, write and probably read etc. for the
AppleDouble file.
If MacFUSE does not interfere here I do not understand why the
position attribute would have an influence for that case.
(wouldn´t the Finder just create and read AppleDouble filechunks?)

Does this mean that I still have no chance getting this to work on the
implementation side if I need to use AppleDouble files?

Thanks for your time,
Thomas

Instead of the Objective-C based LoopbackFS, try the fusexmp_fh
example (the "original" C-based loopback file system for MacFUSE) from
the user-space library. You can mount it as follows:

$ mkdir /tmp/dir
$ mkdir /Volumes/loop
$ ./fusexmp_fh /Volumes/loop -omodules=subdir,subdir=/tmp/dir

This will remount /tmp/dir on /Volumes/loop. Now see what happens with
your xattr experiments. You can comment out the following code from
fusexmp_fh.c to make it use ._ files instead of native xattrs:

#ifdef HAVE_SETXATTR
        .setxattr     = xmp_setxattr,
        .getxattr     = xmp_getxattr,
        .listxattr    = xmp_listxattr,
        .removexattr  = xmp_removexattr,
#endif

The reason I tell you to do this is because the behavior of fusexmp_fh
most closely reflects the state of the MacFUSE API. I see that you are
using the Objective-C bindings, but it's still helpful to know what
fusexmp_fh does.

To compile fusexmp_fh, you can check out the entire MacFUSE source
tree, say, under /work. Then you do the following:

$ cd /work/macfuse/
$ ./tools/build_lib.sh
...

Once it finishes, you should have a build of the user-space library
under /tmp/fuse-2.7.3 (that is, current version). You can find the
compiled example as /tmp/fuse-2.7.3/example/fusexmp_fh.

Amit

On May 8, 12:56 am, freeridecoding <t...@freeridecoding.com> wrote:

I've confirmed that it works fine with fusexmp_fh, so it is not a
problem there. I think I've tracked what it is. Until I figure out the
"proper" solution, I'd like you to try a workaround and let me know if
this fixes the problem for you.  You mentioned that your file system
doesn't implement extended attributes, but try adding only this one
xattr related delegate method:

- (BOOL)setExtendedAttribute:(NSString *)name
                ofItemAtPath:(NSString *)path
                       value:(NSData *)value
                    position:(off_t)position
                       options:(int)options
                       error:(NSError **)error {
  *error = [NSError errorWithDomain:NSPOSIXErrorDomain code:ENOSYS
userInfo:nil];
   return NO;

That explicitly reports that setxattr is not implemented. The current
GMUserFileSystem code prefers to use ENOTSUP for various reasons but
it will honor your error code if you implement the delegate method.

Let me know if it works!

ted

yes, as far as I can confirm with a quick test, the above
implementation solves the issue.
thanks a lot for providing a solution that quickly. i really
appreciate it!

just for my understanding I would be interested to know:

- does the fix added supporting the "position" attribute have any
effect in that case?
- why is ENOTSUP not enough the make the finder believe xattrs are
really not supported?

thank you.

thomas

On May 8, 11:41 am, freeridecoding <t...@freeridecoding.com> wrote:

That's only a temporary fix though. Read below.

It should be enough. Adding support for the position argument
introduces another issue that needs another fix. If you try the latest
svn tree (rev 955 and up), it should work correctly in all your cases.

For reference, xattr rules in MacFUSE are as follows (I'm talking
about the C bindings):

* If you ever return ENOSYS from your callback, the kernel will
remember that as an indication that you do not want to be called for
that xattr function. After that, the kernel will handle that call
through the fallback path (._ files). To maintain sanity, if you want
to return this, you should return it for all 4 xattr calls (getxattr,
setxattr, removexattr, listxattr).

* If you return ENOTSUP from your callback, the kernel will handle
*that* particular invocation through the fallback path (._ files).
Again, to maintain sanity, you'd want to be consistent about this--if
you want to handle certain xattrs natively and have the kernel handle
certain other ones, make your choices, and stick to them.

Amit