I fixed a common Mac problem

And in the process discovered an easter egg

Backup folder is inaccessable

If you’ve ever copied a folder from on disk to another and got interrupted, you may have found yourself with a folder that appears dimmed in the finder and is inaccessible.

This happened to me whist copying 200GB of files from one drive to another and the transfer crashing out after around 150GB. Looking on the web there were 2 ‘solutions’:

1. Do the copy again
2. Set up an alias to the dimmed folder

Neither of these was acceptable. So I started investigating.

The usual suspects

I checked the obvious things:

• The folder wasn’t locked.
• The permissions were normal and gave me full access.
• There was no ACL preventing access.
• There was no hidden flag.
• There was no uchg (immutable) flag.
• The filesystem was Mac OS Extended (Journaled), or HFS+, and Disk
• Utility’s First Aid reported: The volume Backup was to be OK.
• The folder was also perfectly ordinary as far as Spotlight was concerned: kMDItemContentType = “public.folder”

So this wasn’t a damaged folder in any conventional sense. It was a folder that Finder didn’t want me to open.

Then I looked at the Finder metadata

MacOS has a command called GetFileInfo, which reports some of the older Finder metadata associated with a file or directory.

For the troublesome folder it reported:

directory: “Backup/Data”
attributes: avbstclinmedz
created: 01/24/1984 19:00:00
modified: 08/15/2026 01:15:05

That creation date immediately caught my attention:

24 January 1984.

Anyone with an interest in Apple history will recognise the date. It was the day Steve Jobs introduced the original Macintosh.

I changed the creation date to the current date and the folder immediately became accessible in Finder.

Problem solved.

Then I tried an experiment. I created another test folder and set its creation date to:

01/24/1984 19:00:00

The folder became dimmed in Finder. I couldn’t open it.

Then I changed the timestamp by exactly one second:

01/24/1984 19:00:01

The folder immediately became normal again.

Get Realtime’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

01/24/1984 at exactly 19:00:00.

Change it to 19:00:01 and Finder is happy.

January 24, 1984 was the day the Macintosh was introduced. And the time was 19:00:00 UST

And the troublesome timestamp is:

January 24, 1984–19:00:00

Somewhere inside macOS/Finder there is apparently a special significance to this exact timestamp — or at least to the underlying value that this timestamp represents.

The fact that changing it by one second makes the folder usable is difficult to dismiss as ordinary date-handling behaviour.

Perhaps it is an old Macintosh convention that survived through decades of filesystem development or perhaps it is an undocumented sentinel value.

Perhaps it really is an Easter egg.

Or perhaps I’ve simply stumbled across an obscure historical artefact that nobody intended us to notice.

Whatever the explanation, it makes for a remarkably entertaining filesystem bug.

The practical solution

The good news is that you don’t need to copy the folder again.

If you encounter a dimmed folder that Terminal can access normally, check its creation date:

GetFileInfo “/path/to/folder”

If you find:

created: 01/24/1984 19:00:00

you can change the creation date with:

SetFile -d “$(date ‘+%m/%d/%Y %H:%M:%S’)” “/path/to/folder”

And the folder becomes accessible again.

A tiny script

I eventually wrote this little shell script so that I could check a folder without manually changing anything.

It changes the creation date only if it finds the exact problematic timestamp:

#!/bin/bash
 if [ $# -ne 1 ]; 
 then 
  echo "Usage: $0 folder" 
  exit 1 
 fi 
 folder="$1" 
 if [ ! -d "$folder" ]; 
 then 
  echo "Error: '$folder' is not a folder." 
  exit 1 
 fi 
 creation_date=$(GetFileInfo "$folder" | awk -F': ' '/created:/ {print $2}') 
 if [[ "$creation_date" == "01/24/1984 19:00:00" ]]; 
 then 
  echo "Folder has the problematic Macintosh timestamp." 
  echo "Setting creation date to now..." 
  SetFile -d "$(date '+%m/%d/%Y %H:%M:%S')" "$folder" 
  echo "Done." 
 else 
  echo "Creation date is $creation_date" 
  echo "It is not the problematic timestamp - no change made." 
 fi

Usage is simply:

./Fixdate “/Volumes/2TB Backup 2/Movies-old”

The script deliberately checks the entire timestamp, not just the date.