On Mon, Apr 28, 2025 at 3:08 AM Lionel Cons <lionelcons1...@gmail.com> wrote: > > On Sat, 26 Apr 2025 at 17:14, Rick Macklem <rick.mack...@gmail.com> wrote: > > > > On Tue, Apr 22, 2025 at 3:34 AM Cedric Blancher > > <cedric.blanc...@gmail.com> wrote: > > > > > > On Sun, 9 Mar 2025 at 00:02, Rick Macklem <rick.mack...@gmail.com> wrote: > > > > > > > > First off, I cross posted because I don't think many read freebsd-arch@. > > > > There seems to be a nice market for Solaris style extended attributes. > > > > Since ZFS is already wired for them, adding the basics is pretty > > > > straightforward. I am not suggesting that they should replace the > > > > current FreeBSD extended attributes. > > > > > > > > For those not familiar with them (I am not very familiar myself;-), > > > > a Solaris style extended attribute is in a directory that hangs off > > > > the file object and the entries in the directory (the attributes) can > > > > be manipulated with open/read/write/lseek just like a regular file. > > > > (They can be as large as a regular file, but there is no atomicity > > > > guarantees.) > > > > > > > > At this point I have a couple of rough patches: > > > > https://people.freebsd.org/~rmacklem/xattr.patch - the VFS/ZFS part > > > > https://people.freebsd.org/~rmacklem/nfs-xattr.patch - the NFSv4 part > > > > > > Any timeframe when > > > https://people.freebsd.org/~rmacklem/nfs-xattr.patch will land in > > > FreeBSD? > > Should be in main in a week or so. I have already done one patch > > commit, but there are a few more needed. > > > > On the bigger picture... > > I have finally gotten Solaris going in a VM so that I could test stuff > > on it and have found a couple of incompatibilities: > > - I required O_CREAT for > > nameddir_fd = openat(file_fd, ".", O_NAMEDATTR, 0); > > to create the named attribute if it did not already exist. > > Solaris does not require O_CREAT for this case (when used > > with O_XATTR) and actually returns EINVAL. > > Solaris just creates the directory if it does not already exist. > > > > Changing this is a trivial 2 line patch and I think being Solaris > > compatible makes sense. I required the O_CREAT, since I > > was thinking the syscall without it could be used to test to see > > if the named attribute directory exists, but I am not sure if that > > is useful? > > > > Do others think I should change the behavior to be Solaris compatible? > > > > - Solaris allows hard links to be created to a named attribute. > > I did not allow this, since I was concerned that having links to the > > same attribute for multiple file objects might be confusing. > > > > Do others think I should allow them? > > We've been debating this in a staff meeting today: From an API point > of view Windows EA index and Streams (Alternate Data Streams) index is > ALWAYS there, no special creation for the index required. MacOS > Alternate Data Stream does the same, no need to create the index, it > is always there. > > So we think Solaris is right. Another Solaris compatibility question has come up. Solaris uses a pathconf name _PC_XATTR_EXISTS that indicates whether or not a file has named attribute(s) on it. (This is separate from _PC_XATTR_ENABLED, which indicates if the file system has named attribute support.)
I have coded this, but having a pathconf name for something that is specific to a file is a bit weird. kib@ has suggested that it might be better to do it as an ioctl(). So, do you think a pathconf variable is preferred, since it is "Solaris compatible" or an ioctl()? Also, I named it _PC_HAS_NAMEDATTR, but would you prefer _PC_NAMEDATTR_EXISTS for the name, if pathconf() is your preferred approach? Thanks for any input, rick > > Lionel
