Skip to main content

This article applies to Code42 for Enterprise version 4.

Other available versions:

Version 6 | Version 5icon.qnmark.png

Code42 Support

Supported metadata

This article applies to Code42 for Enterprise version 4.

Other available versions:

Version 6 | Version 5icon.qnmark.png


Metadata is data about data. For example, when saving a file, your computer automatically records information about when the file was created or modified. CrashPlan supports restoring metadata, like file modification date, and embedded metadata on all platforms. Restored files will include supported metadata as described in this article.

Why is metadata important?

Metadata gives context to our files and lets us use them in a functional way. For instance, file extensions are a basic form of metadata that give files context. Without a file extension, your computer can’t differentiate a text file from a photo. The file extension metadata tells your computer what applications can open the file.

Restore metadata

Supported metadata is included in your restored files. However, there are several considerations for restoring metadata:

  • CrashPlan app: Metadata cannot be restored via web restore. To preserve metadata, restore from the CrashPlan app.
  • Different operating system: If you restore a file to a different operating system than the one where the file originated, CrashPlan may not be able to restore metadata supported by the original operating system. Restore files on a computer using the original operating system for best results.

What metadata can I restore?

CrashPlan supports restoring specific forms of metadata for each operating system listed below. Since different applications can create and store metadata in different ways, we can’t guarantee that every form of metadata can be restored. However, we have tested CrashPlan for the types listed below.

Normally, metadata is stored within the file that it is describing, but metadata can be created and stored in a number of ways. Some applications store metadata in a separate database file. One example is the metadata created by Lightroom. The CrashPlan app may have difficulty backing up the database file if it is in use, but if you choose to write out that metadata to the file itself, CrashPlan will back it up regularly.

Mac OS X

Supported Unsupported
  • Data fork
  • Resource fork
  • Owner information for regular files and directories
  • Symlink owner information
  • POSIX permissions
  • Finder Flags/Info (including type/creator)
  • Locked flag (this is part of Finder Flags)
  • Modification date
  • Creation date
  • Finder comments (.DS_Store file)
  • ACLs
  • Other named forks
  • BSD Flags, which can be set via chflags
  • HFS+ extended attributes (i.e. xattr)
  • Aliases

Restore to a non-HFS+ file system

When copying a file (and therefore restoring) to a non-HFS+ file system, any info not in the data file is stored in a “dot-underscore” file. For example, if you copy an HFS+ file named MyMug.jpg to a FAT 32 volume, there will be a file named ._MyMug.jpg in addition to the MyMug.jpg file in the same location.


Supported Unsupported

  • Accessed date (version 4.4.1 and later)
  • Archive
  • Created date (version 4.4.1 and later)
  • Directory
  • Normal
  • Modified date
  • Readonly
  • Temporary

  • Compression attribute
  • Created date (version 4.4.0 and earlier)
  • DACL (Discretionary Access Control List)
  • Encrypted
  • Hidden
  • Not_Content_Indexed
  • Offline
  • Reparse_Point
  • Sparse_File
  • System


  • Permissions: UGO, RWX
  • uid
  • gid

Related topics

  • Was this article helpful?