exFAT: orphan file name entries

The exFAT file system was designed with Unicode file names and optional vendor-specific extensions in mind. To keep things simple, the file system specification allows the usage of multiple directory entries to describe a single file (so, additional file metadata is described in additional directory entries). This solution is similar to the VFAT extension for the FAT12/16/32 file systems, which was designed as a hack to the original file system format (originally, only one directory entry was used to describe a single file, so long file names were implemented as additional directory entries, which are “invisible” to operating systems without the VFAT support).

In the exFAT file system, a typical file consists of these entries (in this order, with no other entries between):

  • one file entry,
  • one stream extension entry,
  • one or more file name entries (as needed to store the file name),
  • zero, one or more vendor-specific entries (which can be ignored if not supported).

The first two entries describe all file metadata (its attributes, timestamps, data size, first cluster, etc.), while the file name entries contain strings to form the file name (each file name entry stores no more than 15 Unicode characters and the file name is no longer than 255 characters). Together, these entries are called a directory entry set (and it must contain at least three entries).

When a file is deleted, its directory entry set is marked as free. This process is very similar to what happens to a deleted file in the FAT12/16/32 file systems: the first byte of a directory entry is changed to mark it as free.

And, of course, it is possible to recover a deleted file when its directory set and data clusters are not overwritten. If the directory entry set is partially overwritten (with new directory entries), the following can be observed:

Continue reading “exFAT: orphan file name entries”

macOS & FAT directories

Previously, I wrote about things you probably didn’t know about FAT. Now, let’s continue the story!

In FAT12/16/32 file systems, each directory (except the root directory) contains two special entries:

  • dot (“.”);
  • dot-dot (“..”).

The first one (dot) refers to the directory itself, while the second one (dot-dot) refers to the parent directory. Apparently, these entries were introduced to keep file system implementations simple, so there is no need to generate those entries on the fly (this is what happens to file systems not wasting their space to store dot and dot-dot entries in every directory).

Since two special entries are regular 8.3 directory entries, they contain timestamps (Created, Modified, Last Accessed). According to Microsoft, these timestamps should be set like this:

[…] and all of the date and time fields in both of these entries are set to the same values as they were in the directory entry for the directory that you just created.

FATGEN, 1.03 (DOC)

So, the timestamps in the dot-dot directory entry have no connection to the parent directory of that directory (they aren’t copied from the corresponding timestamp fields of the parent directory). Both special entries have their timestamps set to the same values as in the directory itself.

For example, all these entries are expected to share the same timestamps:

  • E:\test
  • E:\test\.
  • E:\test\..

But are these timestamps always synchronized?

Continue reading “macOS & FAT directories”