Hi Yuan,
My concernn is: what is the expected behavior for opening a symbolic
link, both on the kernel side and the server side? Is it possible for
the fuse server to return the dentry containing the inode of the link
destination instead of the inode of the symbolic link itself?
nfs_atomic_open handles -ELOOP. Possibly fuse server needs to check for
O_NOFOLLOW, but I'm not sure. Will look into that in the morning.
thanks again for testing atomic open and reporting the symlink issue.
And sorry for the delay.
Actually interesting that it was not caught by xfstests (or I somehow
didn't notice) Horst (in CC) is currently adding fuse specific tests -
we will catch it in the future. Will also check for existing symlink
tests - this is actually not fuse specific...
I just pushed an initial fix to
https://github.com/bsbernd/linux/tree/atomic-open-for-6.5-v10
https://github.com/libfuse/libfuse/pull/813
I'm going to add further changes for symlinks, though. Right now atomic
open just reports -ELOOP and then falls back to fuse_create_open, which
sends a lookup - atomic_open now adds in overhead - the opposite of what
I want. I had tried to return the attributes and the error for
atomic_open, but that is not accepted in fuse_dev_do_write(). It would
be possible to hack that function with checks for FUSE_OPEN_ATOMIC, but
it would be rather hackish. So we need to extend fuse_entry_out with the
error code, or add a new struct.
Thanks,
Bernd
