hoakley December 9, 2021 Macs, Technology

Hidden files and folders on APFS volumes

I’ve recently had a few questions from users who typically are trying to copy the contents of an APFS volume, and come across various hidden files and folders at its top level. This article lists some of the most common you’re likely to see, and their significance. You can also find a handy guide to the files and folders which Carbon Copy Cloner doesn’t copy in this excellent article, which additionally covers HFS+ and System volumes. Here I’m primarily concerned with APFS on data volumes.

Folders include:

.DocumentRevisions-V100 which is private data maintained by the macOS versioning system. There’s no point in copying this folder, even if you’re trying to create a perfect replica of a volume, as it appears to contain hard links and a database which won’t survive the transfer. This is normally locked away, and shouldn’t be tampered with unless you want to break the version system on that volume.
.Spotlight-V100 which contains the Spotlight indexes for that volume. Again, this isn’t portable, and shouldn’t be transferred. Instead, if you want Spotlight search to cover the volume, you should allow it to be indexed in the normal way.
.TemporaryItems contains miscellaneous temporary items, and shouldn’t be copied.
.Trashes is the volume’s Trash, and shouldn’t normally be copied.
.fseventsd is the File System Events database, in which details of changes made to files and folders on that volume are recorded. This isn’t portable, so shouldn’t be copied. Time Machine and other software uses it, so it should be left alone. If it becomes lost or damaged, the next TM backup can take longer as it is reconstructed.
.vol is the volume root placemarker for the volfs file system, a pseudo-directory. It’s unique to each volume, and created for that volume, so mustn’t be copied, and left well alone.
.PreviousSystemInformation is apparently of no use and shouldn’t be copied.
.localized may be a folder containing localised versions of the volume name for use by the Finder. It can instead be a zero-length file, indicating that the name can’t be localised. It should be ignored and not copied.

Files include:

.DS_Store is the Desktop Services Data for the volume’s top level, containing custom settings and information for the Finder. This shouldn’t normally be copied, and will be created when the Finder accesses a new volume.
.apdisk apparently stores information about mounted folders from a Windows network, and shouldn’t be copied.
.VolumeIcon.icns refers to any custom icon for that volume, and shouldn’t normally be copied.
.file is the root file inode for the volume’s file system. It’s unique to each volume, created for that volume, and mustn’t be copied, just left well alone.

You may also encounter old remnants from macOS installations, such as the files .installer-compatibility, .TempReceipt.bom and .OSInstallerMessages, and the folders .PKInstallSandboxManager and .PKInstallSandboxManager-SystemSoftware. Those should also be ignored and not copied.

Some third-party software installs hidden files or folders at the top level of data volumes. These should be named in a way that indicates their ownership and purpose, such as
.com.bresink.system.tinkertoolsystem4-0420-Evaluation.do-not-delete
You’ll need to guess what’s best to do with each. Beware that some could be signs of malware.

6Comments

Add yours

1

hhanche on December 9, 2021 at 2:32 pm

.file is really an oddball item in this collection of hidden files. I know what root, file, and inode mean in a file system, but “root file inode” makes no sense to me. Be that as it may, on my system, /.file is empty, has all access turned off for everybody, has a modification time of 2020-01-01 08:00:00 UTC (I think that makes it midnight in Cupertino), and an inode number (hex) 0FFFFFFF00000011 (where I added a leading zero to expose all 64 bits).

To me, that looks like a file system internal feature that was inadvertently exposed to outside world. It makes me wonder what would happen if one tried to remove it. Not that I would dare do so, of course.

Oh, and I only see it on the data volume. None of my other apfs volumes, either internal or external, seem to have this file.

LikeLiked by 1 person
- 2
  
  hoakley on December 9, 2021 at 6:34 pm
  
  Thank you.
  Actually, they’re all oddballs!
  .vol and .file are found on Data volumes, and appear to provide them with volfs and inode numbers which don’t overlap with those on the System volume in the Volume Group. .vol appears to be a directory, but doesn’t behave like one, and .file appears to be a file, but doesn’t behave like one.
  If you look at the inode number for .file, you’ll see that it forms the base for the other inode numbers on that Data volume. And if you compare those with the inode numbers on the System volume, you’ll see that they don’t overlap. I believe this is to ensure that inodes are unique within the Volume Group, rather than just that volume, as would normally be the case. .vol supports a similar scheme to ensure that volfs paths also remain unique within the Volume Group.
  I hope that makes sense.
  Howard.
  
  LikeLike
3

hhanche on December 9, 2021 at 9:14 pm

Yes, having inode numbers not overlapping certainly makes sense given how the data volume and the system volume appear together. Thanks for that little tidbit. But actually, on close look, .file and .vol appear to be on the system volume, not the data volume. And their inode numbers are adjacent: FFFFFFF00000011 and FFFFFFF00000012 respectively. I wonder, though, if they are really on that filesystem, or they are an artifact added by the kernel. That could be so, given their unusual behaviour.

LikeLiked by 1 person
- 4
  
  hoakley on December 9, 2021 at 10:45 pm
  
  I see them both on both System and Data volumes, as indicated in Terminal. They appear at root level /, which represents the root of the System volume. I also see them in /System/Volumes/Data which is the mount point of the Data volume.
  The snag is that both those paths are synthetic, and may not represent what’s in the file system of those volumes, merely how they’re presented to the shell.
  The interesting question, though, is whether those are in the signed and sealed snapshot of the System volume. If they are, they must be fixed values or differences would make the Seal variable between installations. I think that they’re effectively file system constants, which makes them sealable there.
  Howard.
  
  LikeLike
5

Nils on December 10, 2021 at 1:10 pm

On my Mac the 0 byte .localized file is inside my Pictures and Music folder. So “… indicating that the name can’t be localised …” is wrong. It makes a Folder localized. If I add it to a Music folder on my external Disk and place .localized into it, I get a localized Name (Musik in German).

LikeLiked by 1 person
- 6
  
  hoakley on December 10, 2021 at 1:30 pm
  
  Thank you.
  This article isn’t about folder localised naming, but about the hidden files and folders found at the top level of APFS volumes.
  I think you’ll find that the mechanism I’ve described above does apply to volumes, but I’m always ready for someone to explain how the .localized folder works, not just the .localized file at the volume root.
  Howard.
  
  LikeLike

·Comments are closed.

Share this:

Related