When I run CheckDisk on a Windows 8 Consumer Preview volume, I get:

> chkdsk /v S:
The type of the file system is NTFS.
Volume label is Windows 8.

WARNING!  F parameter not specified.
Running CHKDSK in read-only mode.

CHKDSK is verifying files (stage 1 of 3)...
  91392 file records processed.
File verification completed.
  28 large file records processed.
  0 bad file records processed.
  20224 EA records processed.                 <------------------ huh??

Why are there so many extended attributes on the volume? I thought no one used EAs anymore...


As an example, the file \Windows\CSC\v2.0.6 has an extended attribute that contains the string

Ԡ 1X C8A05BC0-3FA8-49E9-8148-61EE14A67687.CSC.DATABASE P X Չ: Չ: ˌΦ]cᑡPcďŠ 4 C8A05BC0-3FA8-49E9-8148-61EE14A67687.CSC.DATABASEEX1 P X _, N0t 08 C8A05BC0-3FA8-49E9-8148-61EE14A67687.CSC.EPOCHEA 8 ͌Φ]cᑡPcďŠ }

which (thanks to an answer below) seems to be related to client-side caching of offline files.

However, it seems like most other EAs are different -- e.g. the file

\Program Files\WindowsApps  

and most other files contains (mostly) the string $KERNEL.PURGE.APPXFICACHE, which doesn't seem to be related. What might this be for?

2 Answers 2


Based on the EA name "CSC.DATABASE", one might guess it is related to client-side caching. That would also explain why there are so many of them, since each cached file probably has them to identify them with the server.

Also, I don't think EAs are particularly seldom used at all. I know for sure that they are used, for instance, by IE to identify a file as having been "downloaded from the web" (which makes Windows Explorer ask before running the file and such things).

  • 1
    +1 for the client-side caching, I'll take a look to see if that's also the case for other files. However: note that EAs (extended attributes) are not the same as ADSs (alternate data streams)! The latter is used by IE to store the attachment zone information that you mentioned, but EAs, as far as I know, were only for compatibility with other OSes (OS/2?) -- people don't use them much, AFAIK.
    – user541686
    Mar 4, 2012 at 8:05
  • I updated the question with another EA -- this one looks different. :)
    – user541686
    Mar 4, 2012 at 8:17

Extended attributes ARE used in Windows, including by the kernel, which uses them to track various security restrictions and enforce them.

See https://docs.microsoft.com/en-us/windows-hardware/drivers/ifs/kernel-extended-attributes

Notably the USN journal of NTFS will be able to safely track changes made to files, so that filesystem snapshots or recovery of the filesystem after an unexpected brutal shutdown (caused by power loss, overheat, or BSOD and reboots) are reliable. These are short secured records added in small EA streams (generally stored themselves within the MFT record without allocating any additional extent, unless the MFT record is too small to fit all streams, in which case they will be inserted in separate NTFS extents allocated for "non-resident" attributes that don't fit in the fixed-size MFT record which is generalyl small and about 1KB, but where some file attributes will ALWAYS be fitted, including basic attributes, and the special attribute containing the map of allocated extents for streams that exceed the capacity, such as the default "$DATA" stream for regular file contents, or indexes for directories; which stream will fit in the MFT record depend on the size of MFT record, which may be tuned when formatting the MFT volume, but which is generally 1KB, i.e. smaller than reguler "clusters" used to allocate space for extents)

Some extended attributes managed by the kernel are:

  • "$KERNEL.PURGE.ESBCACHE": apparently this is used by "Branch Cache" to facilitate the deployment and system updates on remotely managed hosts, allowing domains to enforce their own policies (rather than the default local policies or policies defined by default by Microsoft in Windows).
  • "$KERNEL.PURGE.SEC.FILEHASH": it contains a strong file hash (and the hashing algorithm used) of the file contents: this allows filesystem recovery to detect content corruption.
  • "$KERNEL.PURGE.SEC.CODEINTEGRITY": this small EA contains the code integrity policy flags
  • "$KERNEL.SMARTLOCKER.ORIGINCLAIM": it securely tracks the application that created the file (i.e. the path of its installer or MSI package containing reference signatures)
  • "$CI.CATALOGHINT": this contains the name of a secure *.cat file in Windows catalogs for the package containing a source for that file. Tools like "SFC /SCANNOW" or "DISM /Online Cleanup-Image ScanHealth" can inspect them, and with the help of the previous EAs, it will be be able to securely identify the original package containing the file from which it was installed (if necessary, Windows Update will be able to find, download and reinstall a copy of these packages).

Depending on tools and OS features that you use, or with some drivers, you may have other EAs defined. Many security tools and antimalware add their own EAs to various files or directories (also helping these tools to scan changes more efficiently).

If you use the Microsoft Store, or AppX deployment tools on Windows, there will also be additional EAs for setting the virtual environnement on which they will run (e.g. global settings per machine, or per domain or per user or per online "identity" depedning on the remote service you'll use or with which third party you'll communicate, copy-on-write or full duplication, delayed writes or sync'ed writes, sharing options or policies, granted licences and usage rights, trackers for subscription/payment options on online services; some apps also use them also just like tracking cookies on web pages and will then store personal identifiers or preferences speciic to some file contents or apps, and will be able to sync them with online personal profiles, so that you can use these apps offline, at least for a given period of time...).

If you use some cloud services (not jsut those from Microsoft), they can also sync a local copy for files you use locally the most, while allowing files to be archived online or synchronized to other devices).

Generally EAs are very small (about 100 bytes or so for most of them). Any file in NTFS/ReFS (and other supported filesystems) can have many EAs attached to them for many different applications. The way these EAs are individually encoded is application-dependant. EAs have their own names (like regular files in visible directories, and like ADS streams), except that these names are not intended to be read by humans; so these names are "technical" and not using Unicode. Some EA name prefixes are reserved by Microsoft on Windows filesystems.

Whever these EAs will be resident of not in the MFT (of NTFS or ReFS filesystems) depend on how many are present for a given file. IF they don't fit in the MFT record, NTFS will allocate some extents to locate them elsewhere on the volume. The list of EAs defined for a file are one of its streams, just like the standard attributes, or security attributes (ACLs) or the regular content, or additional streams (such as the stream that tracks that a file was downloaded from the net and may be unsafe, it may track its web domain or IP of origin, and if that domain was accessed with a secure protocol like HTTPS: this allows Windows to display authorization popups for the User, or ask for user elevation permission; ZIP/CAB files have such stream, added by webbrowsers and safe downladers; and zip extracting tools will also propagate that stram on each extracted file if it may be executable or have side effects, including HTML files, fonts, Javascripts, media files, or office documents, that will be opened by default in safe mode by applications using them and that will alert the user that some embedded components like scripts or fonts may be unsafe) It is true that some EAs were designed to provide compatiblity with OS/2 or MacOS (only these EAs are deprecated), but there are still other systems added and using them. And new security systems (including in Windows itself in its kernel or in its services and features) constantly add new ones.

EAs are a key feature of NTFS (and ReFS). They also exist in other non-Windows filesystems (including Ext4 on Linux); for some filesystems that don't have native support for them, they may be stored in a separate subdirectory or in files with special names. EAs are normally not displayed in directory contents (for filesystems that implement them) and do not count in the regular filesizes, so they can be added/removed easily without altering the regular content; they also allow different applications, services or OSes to interoperate with the same files by safely associating their own metadata. So they are safe extensions of existing filesystems (most of the time applications don't have to care about them, the OS or its services will manage them, most often for security erasons and inspection)

EAs are definitely not deprecated. In fact there are much more frequently used today, and have many variants created by the many security solutions developed (if you look at Windows 11, it uses more of them; if you are using Azure services, or join an AD domain, there will be additional EAs, if you use various security tools, not just those from Microsoft, they will add their own, some apps also use them to store DRM right trackers on your purchased medias, along with the decryption keys if needed, plus securely signed counters of devices on which they were authorized, you need to logon to the services to update these signatures or remove a device and its authorizations; EAs have plenty of possible uses, not just for security, but as well for optimizing performances by including processing hints and traces or statistics specific to a given usage; they can also be used to track backups and replications/mirrorings, better than the single legacy "ARCHIVE" bit; EAs have their own distinctive names and are creating a sort of "parallel" filesystem, except that they are generally optional and jsut the appropraite filse or diretories needing them will get those EAs). The interest of placing EAs in the core NTFS/ReFS structure is that their placement is ideal rather than using a separate store elsewhere on volumes (this would be slower, especially when working with network filesystems or hard disks and disk arrays, due to access time: EAs can be retrieved very fast at the same time as basic file attributes are loaded; and they are easier to add/remove dynamically)

  • Just a note, I asked this question in 2012 specifically about Windows 8, whereas my searching suggests the EAs you're citing as examples might actually be from Windows 10 and 11? It would be great if you could at least list what $KERNEL.PURGE.APPXFICACHE (which I cited in my question) does, since otherwise your answer (as good content as it may otherwise be) seems to be about a different OS than I had actually asked about!
    – user541686
    Aug 9 at 8:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.