macos-fuse-t / fuse-t

Other
933 stars 7 forks source link

extended attributes broken on macOS Sonoma #71

Open MichaelEischer opened 1 month ago

MichaelEischer commented 1 month ago

When trying to copy files from a restic mount using fuse-t 1.0.42, cp -r path/in/mountpoint /somewhere/else returns the following errors. Those files have no extended attributes.

cp: restic/.git/refs/tags/v0.16.2: could not copy extended attributes to /Users/user/rrrrrr/.git/refs/tags/v0.16.2: Result too large
cp: restic/.golangci.yml: could not copy extended attributes to /Users/user/rrrrrr/.golangci.yml: Result too large
cp: restic/CONTRIBUTING.md: could not copy extended attributes to /Users/user/rrrrrr/CONTRIBUTING.md: Result too large
cp: restic/GOVERNANCE.md: could not copy extended attributes to /Users/user/rrrrrr/GOVERNANCE.md: Result too large
cp: restic/LICENSE: could not copy extended attributes to /Users/user/rrrrrr/LICENSE: Result too large

Those errors do not occur in fuse-t 1.0.41.

fuse-t.log

MichaelEischer commented 1 month ago

I've also noticed something weird in the debug log. There are lots of Lookup(..) (of the directory entry ..) whereas I don't see those in the debug log of restic on Linux.

macos-fuse-t commented 1 month ago

There was a change in 1.0.42 related to extended attributes. I had to do an ugly workaround for Sonoma because otherwise the libfuse mirror fs sample failed to copy files. I will check your implementation to see why it's not working.

macos-fuse-t commented 4 weeks ago

I sent you a PR that re-enables fuse-t attribute cache. For some reason it was disabled by default. I also fixed a small bug in fuse-t which prevented lookup attribute caching for some user flows. That goes into 1.0.43 version. Additionally I tested file copy with the loopback fs sample provided in the examples folder. When xattr are enabled everything works as expected so if you're sill having trouble with restic just check your implementation against the loopback sample. Looking forward for your feedback

MichaelEischer commented 3 weeks ago

Sorry for the late reply, I missed it among all my other github notifications :see_no_evil: .

I sent you a PR that re-enables fuse-t attribute cache. For some reason it was disabled by default.

Enabling the attribute cache fixes https://github.com/macos-fuse-t/fuse-t/issues/61 . The next restic patch release will contain the changes outlined in https://github.com/macos-fuse-t/fuse-t/issues/61#issuecomment-2336794151, which also fix the hanging file operations.

Additionally I tested file copy with the loopback fs sample provided in the examples folder. When xattr are enabled everything works as expected so if you're sill having trouble with restic just check your implementation against the loopback sample.

I still see the xattr issue. I'll take a look at the sample implementation and report back once I know more.

MichaelEischer commented 3 weeks ago

The xattr error also reproduces with the loopback sample for me. I had to patch the code to set inMemoryXattr to true or otherwise all xattr operations would only return ENOTSUP.

The listxattr calls that result in the Result too large error, just return an empty message back to fuse-t. That is the reply only consists of the message header with appropriately set message ID and msg length that equals the size of the header.

[Edit] I dug a bit through the libfuse C code and from what I can tell it generates the exact same message when there are no xattrs for a node [/Edit]

macos-fuse-t commented 2 weeks ago

I'm unable to reproduce this error on my machine (m1, macos 15.1) . Is it related to a specific file you're trying to copy?

MichaelEischer commented 2 weeks ago

Is it related to a specific file you're trying to copy?

No, all files without xattrs are affected. I guess the main difference is that I've tested on macos 14.7, x86.

macos-fuse-t commented 2 weeks ago

I reproduced it on 14.7, looking for a workaround