Open MichaelEischer opened 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.
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.
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
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.
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]
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?
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.
I reproduced it on 14.7, looking for a workaround
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.Those errors do not occur in fuse-t 1.0.41.
fuse-t.log