Page MenuHomeFreeBSD

vfs_default.c: Add _PC_HAS_NAMEDATTR pathconf name
ClosedPublic

Authored by rmacklem on Sat, May 3, 8:52 PM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, May 27, 7:08 AM
Unknown Object (File)
Sun, May 25, 10:03 PM
Unknown Object (File)
Sun, May 18, 6:08 AM
Unknown Object (File)
Thu, May 15, 12:07 AM
Unknown Object (File)
Fri, May 9, 6:44 AM
Unknown Object (File)
Tue, May 6, 2:08 PM
Unknown Object (File)
Tue, May 6, 10:00 AM
Unknown Object (File)
Tue, May 6, 8:00 AM
Subscribers

Details

Summary

D50139 changes the semantics of O_NAMEDATTR so
that a named attribute directory will be created if it
does not already exist. As such, an open(2) without
O_CREAT cannot be used to test to see if one exists.

This patch adds a new pathconf name _PC_HAS_NAMEDATTR,
which returns 1 if one or more named attributes are associated
with the file. A return of 0 means that there are none, so there
is no need to open(2) the named attribute directory.
This allows applications to avoid creating unnecessary named
attribute directories when the application only wishes to read
named attributes and not create them.

It is also useful for the NFSv4 server, so that it can reply with
a correct named_attr attribute.

Test Plan

Tested for a patched system with files that both have
and do not have named attributes.
(The patched system includes support in ZFS for
_PC_HAS_NAMEDATTR.)

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

Does Solaris use the pathconf() to report xattr existence for the specific node?
IMO it is strange since typical, if not all, _PC reports are about fs and not specific node. Also, _PC operates on path, which is racy when working of files.

Due to this, I suggest to add a fcntl() or ioctl() to query existence of the xattr. It would operate on fd, which removes my worry about usual lookup races.

In D50140#1143762, @kib wrote:

Does Solaris use the pathconf() to report xattr existence for the specific node?
IMO it is strange since typical, if not all, _PC reports are about fs and not specific node. Also, _PC operates on path, which is racy when working of files.

Due to this, I suggest to add a fcntl() or ioctl() to query existence of the xattr. It would operate on fd, which removes my worry about usual lookup races.

I remembered there is fpathconf() operating on fds instead of paths, but I still think that fcntl/ioctl is preferred for file-specific queries.

In D50140#1143762, @kib wrote:

Does Solaris use the pathconf() to report xattr existence for the specific node?

It seems to do so. Solaris calls it _PC_XATTR_EXISTS.
It seems to work for local files on Solaris, but returns random junk for an NFSv4 mount.
(Since things look correct on the wire, I think this is just a Solaris bug?)

IMO it is strange since typical, if not all, _PC reports are about fs and not specific node. Also, _PC operates on path, which is racy when working of files.

I thought the same thing. In fact the description of pathconf(2) describes system limits.

Due to this, I suggest to add a fcntl() or ioctl() to query existence of the xattr. It would operate on fd, which removes my worry about usual lookup races.

I can change it to be an ioctl(). I never said it would be Solaris compatible.

Or I could recommend using fpathconf() in the man page.
(Strangely, Solaris does have pathconf names that can only be used with fpathconf(),
but _PC_XATTR_EXISTS is not one of them.)

So, do you prefer Solaris compatible or an ioctl()?
(I can ask on a mailing list too, but I don't get many responses.)

I think it is slightly better to be similar to Solaris, then to be cleaner, in this place.

This revision is now accepted and ready to land.Sun, May 4, 4:12 PM