| GETATTRLIST(2) | System Calls Manual | GETATTRLIST(2) |
getattrlist,
fgetattrlist, getattrlistat
— get file system attributes
#include
<sys/attr.h>
#include <unistd.h>
int
getattrlist(const
char* path, struct
attrlist * attrList, void
* attrBuf, size_t
attrBufSize, unsigned
long options);
int
fgetattrlist(int
fd, struct attrlist *
attrList, void *
attrBuf, size_t
attrBufSize, unsigned
long options);
int
getattrlistat(int fd,
const char *path, struct attrlist *
attrList, void * attrBuf, size_t
attrBufSize, unsigned long options);
The
getattrlist()
function returns attributes (that is, metadata) of file system objects.
getattrlist() works on the file system object named
by path, while
fgetattrlist()
works on the provided file descriptor fd.
The
getattrlistat()
system call is equivalent to getattrlist() except in
the case where path specifies a relative path. In this
case the attributes are returned for the file system object named by path
relative to the directory associated with the file descriptor
fd instead of the current working directory. If
getattrlistat() is passed the special value
AT_FDCWD in the fd parameter,
the current working directory is used and the behavior is identical to a
call to getattrlist().
You can think of
getattrlist()
as a seriously enhanced version of
stat(2). The functions return attributes
about the specified file system object into the buffer specified by
attrBuf and attrBufSize. The
attrList parameter determines what attributes are
returned. The options parameter lets you control
specific aspects of the function's behavior.
Not all volumes support all attributes. See the discussion of
ATTR_VOL_ATTRIBUTES for a discussion of how to
determine whether a particular volume supports a particular attribute.
Furthermore, you should only request the attributes that you need.
Some attributes are expensive to calculate on some volume formats. For
example, ATTR_DIR_ENTRYCOUNT is usually expensive to
calculate on non-HFS [Plus] volumes. If you don't need a particular
attribute, you should not ask for it.
The path parameter must reference a valid file system object. Read, write or execute permission of the object itself is not required, but all directories listed in the path name leading to the object must be searchable.
The attrList parameter is a pointer to an attrlist structure, as defined by ⟨sys/attr.h⟩ (shown below). It determines what attributes are returned by the function. You are responsible for filling out all fields of this structure before calling the function.
typedef u_int32_t attrgroup_t;
struct attrlist {
u_short bitmapcount; /* number of attr. bit sets in list */
u_int16_t reserved; /* (to maintain 4-byte alignment) */
attrgroup_t commonattr; /* common attribute group */
attrgroup_t volattr; /* volume attribute group */
attrgroup_t dirattr; /* directory attribute group */
attrgroup_t fileattr; /* file attribute group */
attrgroup_t forkattr; /* fork attribute group */
};
#define ATTR_BIT_MAP_COUNT 5
The fields of the attrlist structure are defined as follows.
ATTR_BIT_MAP_COUNT.Unless otherwise noted in the lists below, attributes are read-only. Attributes labelled as read/write can be set using setattrlist(2).
The attrBuf and attrBufSize parameters specify a buffer into which the function places attribute values. The format of this buffer is sufficiently complex that its description requires a separate section (see below). The initial contents of this buffer are ignored.
The options parameter is a bit set that controls the behaviour of the functions. The following option bits are defined.
getattrlist()
will not follow a symlink if it occurs as the last component of
path.getattrlist() will not follow
a symlink if it occurs as the last component of
path. In addition an error is returned if a symlink
is encountered before the last component of
path.ATTR_CMN_RETURNED_ATTRS be requested.ATTR_CMN_GEN_COUNT and
ATTR_CMN_DOCUMENT_ID can be requested. When this
option is used, forkattrs are reinterpreted as a set of extended common
attributes.The data returned in the buffer described by attrBuf and attrBufSize is formatted as follows.
If the attribute is of variable length, it is represented in the list by an attrreference structure, as defined by ⟨sys/attr.h⟩ (shown below).
typedef struct attrreference {
int32_t attr_dataoffset;
u_int32_t attr_length;
} attrreference_t;
This structure contains a 'pointer' to the variable length attribute data. The attr_length field is the length of the attribute data (in bytes). The attr_dataoffset field is the offset in bytes from the attrreference structure to the attribute data. This offset will always be a multiple of sizeof(u_int32_t) bytes, so you can safely access common data types without fear of alignment exceptions.
The
getattrlist()
function will silently truncate attribute data if
attrBufSize is too small. The length field at the
front of the attribute list always represents the length of the data
actually copied into the attribute buffer. If the data is truncated, there
is no easy way to determine the buffer size that's required to get all of
the requested attributes. You should always pass an
attrBufSize that is large enough to accommodate the
known size of the attributes in the attribute list (including the leading
length field).
Because the returned attributes are simply
truncated if the buffer is too small, it's possible for a variable length
attribute to reference data beyond the end of the attribute buffer. That is,
it's possible for the attribute data to start beyond the end of the
attribute buffer (that is, if attrRef is a pointer to
the attrreference_t, ( ( (char *)
attrRef ) + attr_dataoffset )
> ( ( (char *) attrBuf ) +
attrSize ) ) or, indeed, for the attribute data to
extend beyond the end of the attribute buffer (that is, ( ( (char *)
attrRef ) + attr_dataoffset +
attr_datalength ) > ( ( (char *)
attrBuf ) + attrSize ) ). If
this happens you must increase the size of the buffer and call
getattrlist()
to get an accurate copy of the attribute.
Common attributes relate to all types of file system objects. The following common attributes are defined.
NAME_MAX + 1 characters, which is
NAME_MAX * 3 + 1 bytes (as one UTF-8-encoded
character may take up to three bytes).On HFS+ volumes, the ATTR_CMN_OBJID of a file system object is distinct from the ATTR_CMN_OBJID of any hard link to that file system object. Although the ATTR_CMN_OBJID of a file system object may appear similar (in whole or in part) to it's ATTR_CMN_FILEID (see description of ATTR_CMN_FILEID below), no relation between the two attributes should ever be implied.
ATTR_CMN_OBJID is deprecated sarting with
macOS 10.13, iOS 11.0, watchOS 4.0 and tvOS 11.0 and ATTR_CMNEXT_LINKID
should be used in its place. ATTR_CMN_OBJID can only be used on older
operating systems only if the file system doesn't 64 bit IDs. See the
getLinkIDInfo()
function in the EXAMPLES section.
Some file systems can not return this attribute when the
volume is mounted read-only and will fail the request with error
EROFS.
(e.g. original HFS modifies on disk structures to generate persistent
identifiers, and hence cannot do so if the volume is mounted read
only.)
If a file system object is hard linked from multiple directories, the parent directory returned for this attribute is non deterministic; it can be any one of the parent directories of this object. For some volume formats the computing cost for this attribute is significant; developers are advised to request this attribute sparingly.
This attribute is not byte swapped by the file system. The value of multibyte fields on disk is always big endian. When running on a little endian system (such as Darwin on x86), you must byte swap any multibyte fields.
~S_IFMT.A generation count value of 0 is invalid and cannot be used to determine data change.
The generation count is invalid while a file is mmap'ed. An invalid generation count value of 0 will be returned for mmap'ed files.
A document id of 0 is invalid.
R_OK, W_OK, and
X_OK, respectively. See
access(2) for more details.ATTR_CMN_OWNERID.ATTR_CMN_GRPID.PATH_MAX. Inconsistent behavior may be
observed when this attribute is requested on hard-linked items,
particularly when the file system does not support ATTR_CMN_PARENTID
natively. Callers should be aware of this when requesting the full path of
a hard-linked item.Volume attributes relate to volumes (that is, mounted file systems). The following volume attributes are defined.
ATTR_VOL_INFO
in the volattr field if you request any other volume
attributes.ATTR_VOL_SPACEAVAIL is to
ATTR_VOL_SPACEFREE as
f_bavail is to f_bfree in
statfs(2).
MAXPATHLEN. Equivalent to the
f_mntonname field of the
statfs structure returned by
statfs(2).NAME_MAX
+ 1.
This attribute is only read/write if the
VOL_CAP_INT_VOL_RENAME bit is set in the volume
capabilities (see below).
MAXPATHLEN.MFSTYPENAMELEN.The following directory attributes are defined.
DIR_MNTSTATUS_MNTPOINT, which indicates that there
is a file system mounted on this directory.Requested directory attributes are not returned for file system objects that are not directories.
The following file attributes are defined.
This attributes exists for compatibility reasons. New clients
should not use this attribute. Rather, they should use the
F_LOG2PHYS command in
fcntl(2).
In current implementations the value may not be entirely accurate for a variety of reasons.
See also ATTR_FILE_DATAEXTENTS.
File attributes are used for any file system object that is not a directory, not just ordinary files. Requested file attributes are not returned for file system objects that are directories.
Fork attributes relate to the actual data in the file, which can be held in multiple named contiguous ranges, or forks. These cannot be used if the FSOPT_ATTR_CMN_EXTENDED is given. The following fork attributes are defined.
Fork attributes are deprecated and all bits are reserved. They are not properly implemented by any current Mac OS X volume format implementation. We strongly recommend that client programs do not request fork attributes. If you are implementing a volume format, you should not support these attributes.
Common extended attributes are like common attributes except that they are set in the forkattr field and can only be used if the FSOPT_ATTR_CMN_EXTENDED option is given. Use of these attributes is mutually exclusive with the above fork attributes.
PATH_MAX. Inconsistent behavior may be observed
when this attribute is requested on hard-linked items, particularly when
the file system does not support ATTR_CMN_PARENTID natively. Callers
should be aware of this when requesting the relative path of a hard-linked
item.On HFS+ and APFS volumes, the ATTR_CMNEXT_LINKID of a file system object is distinct from the ATTR_CMNEXT_LINKID of any hard link to that file system object. Although the ATTR_CMNEXT_LINKID of a file system object may appear similar (in whole or in part) to its ATTR_CMN_FILEID (see description of ATTR_CMN_FILEID above), no relation between the two attributes should ever be implied.
PATH_MAX. Inconsistent behavior may be observed
when this attribute is requested on hard-linked items, particularly when
the file system does not support ATTR_CMN_PARENTID natively. Callers
should be aware of this when requesting the canonical path of a
hard-linked item.Not all volumes support all features. The
ATTR_VOL_CAPABILITIES attribute returns a
vol_capabilities_attr_t structure (shown below) that
indicates which features are supported by the volume.
typedef u_int32_t vol_capabilities_set_t[4];
#define VOL_CAPABILITIES_FORMAT 0
#define VOL_CAPABILITIES_INTERFACES 1
#define VOL_CAPABILITIES_RESERVED1 2
#define VOL_CAPABILITIES_RESERVED2 3
typedef struct vol_capabilities_attr {
vol_capabilities_set_t capabilities;
vol_capabilities_set_t valid;
} vol_capabilities_attr_t;
The structure contains two fields, capabilities and valid. Each consists of an array of four elements. The arrays are indexed by the following values.
VOL_CAP_FMT_PERSISTENTOBJECTIDS and so on,
below.VOL_CAP_INT_SEARCHFS and so on, below.The valid field contains bit sets that indicate which flags are known to the volume format implementation. Each bit indicates whether the contents of the corresponding bit in the capabilities field is valid.
The capabilities field contains bit sets that indicate whether a particular feature is implemented by this volume format.
The following bits are defined in the first element (indexed by
VOL_CAPABILITIES_FORMAT) of the
capabilities and valid fields of
the vol_capabilities_attr_t structure.
ATTR_CMN_OBJPERMANENTID for details about how to
obtain these identifiers.Introduced with Darwin 7.0 (Mac OS X version 10.3).
VOL_CAP_FMT_JOURNAL is also set.
Introduced with Darwin 7.0 (Mac OS X version 10.3).
Introduced with Darwin 7.0 (Mac OS X version 10.3).
ATTR_FILE_ALLOCSIZE <
ATTR_FILE_TOTALSIZE ).
Introduced with Darwin 7.0 (Mac OS X version 10.3).
Introduced with Darwin 7.0 (Mac OS X version 10.3).
Introduced with Darwin 7.0 (Mac OS X version 10.3).
VOL_CAP_FMT_CASE_SENSITIVE must also set
VOL_CAP_FMT_CASE_PRESERVING.
Introduced with Darwin 7.0 (Mac OS X version 10.3).
Introduced with Darwin 7.0 (Mac OS X version 10.3).
Introduced with Darwin 8.0 (Mac OS X version 10.4).
UF_HIDDEN file flag, and the
UF_HIDDEN flag is mapped to that volume's native
"hidden" or "invisible" bit (e.g., the invisible bit
from the Finder Info extended attribute).Introduced with Darwin 10.0 (Mac OS X version 10.6).
The following bits are defined in the second element (indexed by
VOL_CAPABILITIES_INTERFACES) of the
capabilities and valid fields of
the vol_capabilities_attr_t structure.
getattrlist()
and setattrlist(2).Introduced with Darwin 7.0 (Mac OS X version 10.3).
Introduced with Darwin 7.0 (Mac OS X version 10.3).
F_PREALLOCATE selector of
fcntl(2).
Introduced with Darwin 7.0 (Mac OS X version 10.3).
Introduced with Darwin 7.0 (Mac OS X version 10.3).
F_GETLK,
F_SETLK, and F_SETLKW
selectors to fcntl(2).
Introduced with Darwin 7.0 (Mac OS X version 10.3).
O_EXLOCK and O_SHLOCK
flags to open(2).
Introduced with Darwin 7.0 (Mac OS X version 10.3).
Introduced with Darwin 8.0 (Mac OS X version 10.4).
Introduced with Darwin 8.0 (Mac OS X version 10.4).
F_PUNCHOLE operation. See
fcntl(2) for more details.A volume can also report which attributes it supports. This
information is returned by the ATTR_VOL_ATTRIBUTES
attribute, which returns a vol_attributes_attr_t
structure (shown below).
typedef struct attribute_set {
attrgroup_t commonattr; /* common attribute group */
attrgroup_t volattr; /* volume attribute group */
attrgroup_t dirattr; /* directory attribute group */
attrgroup_t fileattr; /* file attribute group */
attrgroup_t forkattr; /* fork attribute group */
} attribute_set_t;
typedef struct vol_attributes_attr {
attribute_set_t validattr;
attribute_set_t nativeattr;
} vol_attributes_attr_t;
The validattr field consists of a number of
bit sets that indicate whether an attribute is supported by the volume
format implementation. The nativeattr is similar
except that the bit sets indicate whether an attribute is supported natively
by the volume format. An attribute is supported natively if the volume
format implementation does not have to do any complex conversions to access
the attribute. For example, a volume format might support persistent object
identifiers, but doing so requires a complex table lookup that is not part
of the core volume format. In that case, the
ATTR_VOL_ATTRIBUTES attribute would return
ATTR_CMN_OBJPERMANENTID set in the
validattr field of the
vol_attributes_attr_t, but not in the
nativeattr field.
Upon successful completion a value of 0 is returned. Otherwise, a value of -1 is returned and errno is set to indicate the error.
Not all volumes support getattrlist(). The
best way to test whether a volume supports this function is to simply call
it and check the error result. getattrlist() will
return ENOTSUP if it is not supported on a
particular volume.
The getattrlist() function has been
undocumented for more than two years. In that time a number of volume format
implementations have been created without a proper specification for the
behaviour of this routine. You may encounter volume format implementations
with slightly different behaviour than what is described here. Your program
is expected to be tolerant of this variant behaviour.
If you're implementing a volume format that supports
getattrlist(), you should be careful to support the
behaviour specified by this document.
getattrlist() and
fgetattrlist() will fail if:
ENOTSUP]ENOTDIR]getattrlist()
is not a directory.ENAMETOOLONG]getattrlist()
exceeded NAME_MAX characters, or an entire path
name exceeded PATH_MAX characters.ENOENT]getattrlist() does not
exist.EBADF]fgetattrlist() is
not a valid file descriptor.EACCES]getattrlist().ELOOP]getattrlist().ELOOP]getattrlist().EFAULT]ERANGE]EINVAL]ATTR_BIT_MAP_COUNT.EINVAL]EINVAL]EINVAL]EINVAL]EROFS]EIO]In addition to the errors returned by the
getattrlist(), the
getattrlistat() function may fail if:
If you request any volume attributes, you must set
ATTR_VOL_INFO in the volattr
field, even though it generates no result in the attribute buffer.
The order that attributes are stored in the attribute buffer
almost invariably matches the order of attribute mask bit values. For
example, ATTR_CMN_NAME (0x00000001) comes before
ATTR_CMN_DEVID (0x00000002) because its value is
smaller. When ordering attributes, you should always use the order in which
they are described above.
The timespec structure is 64-bits (two 32-bit elements) in 32-bit code, and 128-bits (two 64-bit elements) in 64-bit code; however, it is aligned on a 4-byte (32-bit) boundary, even in 64-bit code.
If you use a structure for the attribute data, it must be correctly packed and aligned (see examples).
Inconsistent behavior may be observed when the ATTR_CMN_FULLPATH attribute is requested on hard-linked items, particularly when the file system does not support ATTR_CMN_PARENTID natively. Callers should be aware of this when requesting the full path of a hard-linked item, especially if the full path crosses mount points.
For more caveats, see also the compatibility notes above.
The following code prints the file type and creator of a file, assuming that the volume supports the required attributes.
#include <assert.h>
#include <stdio.h>
#include <string.h>
#include <sys/attr.h>
#include <sys/errno.h>
#include <unistd.h>
#include <sys/vnode.h>
typedef struct attrlist attrlist_t;
struct FInfoAttrBuf {
u_int32_t length;
fsobj_type_t objType;
char finderInfo[32];
} __attribute__((aligned(4), packed));
typedef struct FInfoAttrBuf FInfoAttrBuf;
static int FInfoDemo(const char *path)
{
int err;
attrlist_t attrList;
FInfoAttrBuf attrBuf;
memset(&attrList, 0, sizeof(attrList));
attrList.bitmapcount = ATTR_BIT_MAP_COUNT;
attrList.commonattr = ATTR_CMN_OBJTYPE | ATTR_CMN_FNDRINFO;
err = getattrlist(path, &attrList, &attrBuf, sizeof(attrBuf), 0);
if (err != 0) {
err = errno;
}
if (err == 0) {
assert(attrBuf.length == sizeof(attrBuf));
printf("Finder information for %s:\n", path);
switch (attrBuf.objType) {
case VREG:
printf("file type = '%.4s'\n", &attrBuf.finderInfo[0]);
printf("file creator = '%.4s'\n", &attrBuf.finderInfo[4]);
break;
case VDIR:
printf("directory\n");
break;
default:
printf("other object type, %d\n", attrBuf.objType);
break;
}
}
return err;
}
The following code is an alternative implementation that uses nested structures to group the related attributes.
#include <assert.h>
#include <stdio.h>
#include <stddef.h>
#include <string.h>
#include <sys/attr.h>
#include <sys/errno.h>
#include <unistd.h>
#include <sys/vnode.h>
typedef struct attrlist attrlist_t;
struct FInfo2CommonAttrBuf {
fsobj_type_t objType;
char finderInfo[32];
} __attribute__((aligned(4), packed));
typedef struct FInfo2CommonAttrBuf FInfo2CommonAttrBuf;
struct FInfo2AttrBuf {
u_int32_t length;
FInfo2CommonAttrBuf common;
} __attribute__((aligned(4), packed));;
typedef struct FInfo2AttrBuf FInfo2AttrBuf;
static int FInfo2Demo(const char *path)
{
int err;
attrlist_t attrList;
FInfo2AttrBuf attrBuf;
memset(&attrList, 0, sizeof(attrList));
attrList.bitmapcount = ATTR_BIT_MAP_COUNT;
attrList.commonattr = ATTR_CMN_OBJTYPE | ATTR_CMN_FNDRINFO;
err = getattrlist(path, &attrList, &attrBuf, sizeof(attrBuf), 0);
if (err != 0) {
err = errno;
}
if (err == 0) {
assert(attrBuf.length == sizeof(attrBuf));
printf("Finder information for %s:\n", path);
switch (attrBuf.common.objType) {
case VREG:
printf(
"file type = '%.4s'\n",
&attrBuf.common.finderInfo[0]
);
printf(
"file creator = '%.4s'\n",
&attrBuf.common.finderInfo[4]
);
break;
case VDIR:
printf("directory\n");
break;
default:
printf(
"other object type, %d\n",
attrBuf.common.objType
);
break;
}
}
return err;
}
The following example shows how to deal with variable length attributes. It assumes that the volume specified by path supports the necessary attributes.
#include <assert.h>
#include <stdio.h>
#include <stddef.h>
#include <string.h>
#include <sys/attr.h>
#include <sys/errno.h>
#include <unistd.h>
#include <sys/vnode.h>
typedef struct attrlist attrlist_t;
struct VolAttrBuf {
u_int32_t length;
u_int32_t fileCount;
u_int32_t dirCount;
attrreference_t mountPointRef;
attrreference_t volNameRef;
char mountPointSpace[MAXPATHLEN];
char volNameSpace[MAXPATHLEN];
} __attribute__((aligned(4), packed));
typedef struct VolAttrBuf VolAttrBuf;
static int VolDemo(const char *path)
{
int err;
attrlist_t attrList;
VolAttrBuf attrBuf;
memset(&attrList, 0, sizeof(attrList));
attrList.bitmapcount = ATTR_BIT_MAP_COUNT;
attrList.volattr = ATTR_VOL_INFO
| ATTR_VOL_FILECOUNT
| ATTR_VOL_DIRCOUNT
| ATTR_VOL_MOUNTPOINT
| ATTR_VOL_NAME;
err = getattrlist(path, &attrList, &attrBuf, sizeof(attrBuf), 0);
if (err != 0) {
err = errno;
}
if (err == 0) {
assert(attrBuf.length > offsetof(VolAttrBuf, mountPointSpace));
assert(attrBuf.length <= sizeof(attrBuf));
printf("Volume information for %s:\n", path);
printf("ATTR_VOL_FILECOUNT: %u\n", attrBuf.fileCount);
printf("ATTR_VOL_DIRCOUNT: %u\n", attrBuf.dirCount);
printf(
"ATTR_VOL_MOUNTPOINT: %.*s\n",
(int) attrBuf.mountPointRef.attr_length,
( ((char *) &attrBuf.mountPointRef)
+ attrBuf.mountPointRef.attr_dataoffset )
);
printf(
"ATTR_VOL_NAME: %.*s\n",
(int) attrBuf.volNameRef.attr_length,
( ((char *) &attrBuf.volNameRef)
+ attrBuf.volNameRef.attr_dataoffset )
);
}
return err;
}
The following sample demonstrates the need to use packing and alignment controls; without the attribute, in 64-bit code, the fields of the structure are not placed at the locations that the kernel expects.
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <err.h>
#include <time.h>
#include <sys/attr.h>
/* The alignment and packing attribute is necessary in 64-bit code */
struct AttrListTimes {
u_int32_t length;
struct timespec st_crtime;
struct timespec st_modtime;
} __attribute__((aligned(4), packed));
main(int argc, char **argv)
{
int rv;
int i;
for (i = 1; i < argc; i++) {
struct attrlist attrList;
struct AttrListTimes myStat = {0};
char *path = argv[i];
memset(&attrList, 0, sizeof(attrList));
attrList.bitmapcount = ATTR_BIT_MAP_COUNT;
attrList.commonattr = ATTR_CMN_CRTIME |
ATTR_CMN_MODTIME;
rv = getattrlist(path, &attrList, &myStat, sizeof(myStat), 0);
if (rv == -1) {
warn("getattrlist(%s)", path);
continue;
}
printf("%s: Modification time = %s", argv[i], ctime(&myStat.st_modtime.tv_sec));
}
return 0;
}
The getLinkIDInfo() function determines if ATTR_CMNEXT_LINKID and
ATTR_CMN_OBJID
are valid to use on the file system specified by path.
int getLinkIDInfo(const char *path, bool *cmnExtLinkIDValid, bool *cmnObjIDValid)
{
int result;
struct statfs statfsBuf;
struct attrlist attrList;
struct volAttrsBuf {
u_int32_t length;
vol_capabilities_attr_t capabilities;
vol_attributes_attr_t attributes;
} __attribute__((aligned(4), packed));
struct volAttrsBuf volAttrs;
memset(&attrList, 0, sizeof(attrList));
attrList.bitmapcount = ATTR_BIT_MAP_COUNT;
attrList.volattr = ATTR_VOL_INFO | ATTR_VOL_CAPABILITIES | ATTR_VOL_ATTRIBUTES;
// get the file system's mount point path for the input path
result = statfs(path, &statfsBuf);
if ( result == 0 ) {
// get the supported capabilities and attributes
result = getattrlist(statfsBuf.f_mntonname, &attrList, &volAttrs, sizeof(volAttrs), FSOPT_ATTR_CMN_EXTENDED);
if ( result == 0 ) {
if ( volAttrs.attributes.validattr.forkattr & ATTR_CMNEXT_LINKID ) {
// ATTR_CMNEXT_LINKID is available; do not use ATTR_CMN_OBJID
*cmnExtLinkIDValid = true;
*cmnObjIDValid = false;
}
else {
// ATTR_CMNEXT_LINKID is not available
cmnExtLinkIDValid = false;
// ATTR_CMN_OBJID can only be used if the file system does not use 64-bit object IDs
if ( (volAttrs.capabilities.capabilities[VOL_CAPABILITIES_FORMAT] & VOL_CAP_FMT_64BIT_OBJECT_IDS) && (volAttrs.capabilities.valid[VOL_CAPABILITIES_FORMAT] & VOL_CAP_FMT_64BIT_OBJECT_IDS) ) {
*cmnObjIDValid = false;
}
else {
*cmnObjIDValid = true;
}
}
}
}
if ( result != 0 ) {
*cmnExtLinkIDValid = *cmnObjIDValid = false;
}
return result;
}
access(2), chflags(2), exchangedata(2), fcntl(2), getattrlistbulk(2), mount(2), searchfs(2), setattrlist(2), stat(2), statfs(2)
A getattrlist() function call appeared in
Darwin 1.3.1 (Mac OS X version 10.0). The
getattrlistat() function call appeared in OS X 10.10
.
| March 28, 2024 | Darwin |