| Previous | Next |
| STATUS_NONEXISTENT_EA_ENTRY | STATUS_EA_CORRUPT_ERROR |
STATUS_NO_EAS_ON_FILE
Meaning and context of STATUS_NO_EAS_ON_FILE
Extended file attributes are file system features that enable users to associate computer files with metadata not interpreted by the filesystem, whereas regular attributes have a purpose strictly defined by the filesystem (such as permissions or records of creation and modification times). Unlike forks, which can usually be as large as the maximum file size, extended attributes are usually limited in size to a value significantly smaller than the maximum file size. Typical uses include storing the author of a document, the character encoding of a plain-text document, or a checksum, cryptographic hash or digital certificate, and discretionary access control information.
In Unix-like systems, extended attributes are usually abbreviated as xattr.
On Windows NT, limited-length extended attributes are supported by FAT, HPFS, and NTFS. This was implemented as part of the OS/2 subsystem. They are notably used by the NFS server of the Interix POSIX subsystem in order to implement Unix-like permissions. The Windows Subsystem for Linux added in the Windows 10 Anniversary Update uses them for similar purposes, storing the Linux file mode, owner, device ID (if applicable), and file times in the extended attributes.
Additionally, NTFS can store arbitrary-length extended attributes in the form of alternate data streams (ADS), a type of resource fork. Plugins for the file manager Total Commander, like NTFS Descriptions and QuickSearch eXtended support filtering the file list by or searching for metadata contained in ADS. NTFS-3G supports mapping ADS to extended attributes in FUSE; it also maps file attributes that way.
Native status interpretation
STATUS_NO_EAS_ON_FILE is 0xC0000052, an NTSTATUS error value. AllStat describes it as “The file for which EAs were requested has no EAs.”. The first useful question is which native API, IRP, protocol operation, or subsystem in the kernel, native API, or subsystem that returned the status produced that status.
Debugging sequence
- Preserve this result before RtlNtStatusToDosError, HRESULT conversion, exception translation, or provider-specific remapping removes information.
- Compare the exact eas / on / file operation on a working system and record differences in object lifetime, access token, device state, negotiated protocol, and policy.
- For kernel I/O, keep the device stack, IRP major/minor function, request parameters, completion routine, and the first component that completed the request with this result.
Recovery considerations
A retry is appropriate only after the owner of this result has changed the state described by “The file for which EAs were requested has no EAs.”, or when its contract explicitly marks the status as transient. If the value reports corruption, invalid format, access policy, or a lifecycle mismatch, preserve evidence and correct that cause before repeating the request.
Official references
Looking for a different code? Search another status or error code.