# How to recover an overwritten file on a Mac

Recovering an overwritten file on a Mac means finding whichever layer still has it - the app's own Revert To, a Time Machine snapshot, a synced folder's version history - and the gap all three leave is an unsynced folder edited by an app that versions nothing.

- URL: https://swiftfox.studio/handbook/recover-an-overwritten-file-on-mac
- About: https://swiftfox.studio/apps/retrace
- Published: 2026-08-27
- Updated: 2026-09-05
- Publisher: Swiftfox Studio (https://swiftfox.studio)

## In short

- macOS already holds three partial answers: File > Revert To in apps that adopted document versioning, Time Machine's hourly local snapshots kept for 24 hours, and your cloud folder's version history, which covers only that folder.
- Retrace watches only the folders you right-click in Finder, and each one either saves a copy seconds after a file stops changing or waits for a snapshot you ask for - from the folder, from the Finder, or with a shortcut from any app. When a file was not edited but replaced, it says so and keeps what was underneath.
- Its copies are APFS clones, so a version costs effectively nothing to take; keeping is what costs, which is why retention rules and a per-folder disk budget are where the pressure is managed.
- A rewind captures the folder's current state first, so undoing the rewind is just rewinding back to that moment - and that is undoable too.
- It is not a backup: the history sits on the same disk as the folder. $8.99 one-time, with a 30-day trial that needs no card and no email.

## The four places a previous version might already be

Before you install anything, check the four places your Mac may already be
holding the file you want. Each covers a different narrow case, and working out
which one you are in is most of the job.

**File > Revert To, inside the app.** macOS has had document versioning built in
for years, and an app that adopts it gets a `File > Revert To > Browse All
Versions` menu putting that one document's past saves on a timeline. TextEdit,
Preview, Pages, Numbers and Keynote have it. Most of what people actually work
in does not: no Adobe app, no Office app, nothing a script wrote.

**Time Machine.** With Back Up Automatically on, macOS takes a local APFS
snapshot of the startup disk roughly every hour and keeps it for 24 hours, plus
one of the last successful backup. Two limits decide whether that helps: the
granularity is an hour rather than a save, and anything older than a day exists
only if the backup disk is attached.

**Your cloud folder's version history.** Dropbox keeps 30 days of versions on
Basic and Plus and 180 on Professional. Google Drive keeps one for 30 days or
until 100 newer ones exist, unless you marked it Keep forever. iCloud Drive is
the odd one out: its 30-day Recently Deleted recovers files you deleted, not
versions you overwrote. All three cover exactly one folder, the synced one.

**The app's own autosave.** Worth a look, rarely worth counting on. It is undo,
and undo dies with the process.

If one of those has your file, stop reading. What follows is for the case none
of them covers: a folder that is not synced, edited by an app with no version
menu, broken more than an hour ago, or broken across more than one file at once.
[Retrace](https://swiftfox.studio/apps/retrace) is a native macOS app built for that case, and
everything below is in the shipping version.

## Turning history on is a right-click

![The Finder right-click menu with Retrace's History submenu open, showing Enable History, Disable History, Take a Snapshot Now, Restore Previous Version and Show History](https://swiftfox.studio/retrace/listing/shot-4.jpg "The whole setup is one context menu. There is no default folder, because guessing which folders matter is how this kind of app becomes the problem.")

You right-click a folder in Finder, choose **History**, and switch it on. There
is no default folder, no picker to hunt through, and nothing else to configure.
Right-click again to switch it off.

Five items sit under History, in three groups: turning it on or off, acting on
what you clicked - take a snapshot of this folder, restore the previous version
of this file - and opening the app. They are always all present and always in
that order, and whatever is not actionable right now is dimmed rather than
removed, so the gesture is the same one every time. That is also how the menu
says what it is looking at without a second indicator: the snapshot is live only
on a folder that waits to be asked, and the restore only on a file.

Behind the menu is the one real cost of staying inside the App Sandbox. A Finder
extension can hand over the path you right-clicked and nothing else, because a
path from another process is not permission. So the first run asks once for your
home folder and keeps that grant, after which the menu can just work; without it
the same action opens a folder picker instead.

A watched folder also needs proof that it is still being watched. A
security-scoped grant can quietly stop resolving - a volume goes missing, an OS
update invalidates a batch of bookmarks - and nothing in macOS reports it; the
stream simply stops delivering. For an app whose whole promise is "you will not
lose this" that is worse than a crash, so every folder is re-resolved on a
schedule with a real test read, and one that has stopped recording says so in
the list instead of looking fine.

## Why keeping a copy of everything costs nothing

On APFS, `copyfile` with `COPYFILE_CLONE` makes a copy-on-write clone: a new
file that shares the original's data blocks. It costs about zero bytes at
creation and microseconds of wall clock - a 64 MB clone measures around 0.1 ms
and reports zero bytes of its own - and it stays a correct snapshot under both
ways an app can save. An editor that rewrites the file in place allocates fresh
blocks and leaves the clone holding the old ones; an editor that saves
atomically writes a whole new file the clone was never attached to.

That last property is exactly what a hardlink lacks, which is why the classic
hardlink-tree approach was never an option: a hardlink *is* the same file, so an
in-place writer would silently rewrite the version you thought you had kept.

Because capturing is free, Retrace captures eagerly and lets a content hash
decide afterwards whether the capture counted. What is not free is keeping, and
a clone gets more expensive as the original drifts away from it. So the figure
the app shows is what deleting the history would actually free, not what the
versions add up to on paper: thirty clones of one 40 MB file are 1.2 GB by the
naive measure and 40 MB in reality.

Cloning is a property of the volume rather than of the app, and an external
drive formatted HFS+ or exFAT cannot do it at all. Retrace checks up front and
refuses the folder, instead of turning every capture into a silent full copy.

## Knowing when a file is finished

Nothing on macOS answers this properly. The signal that would - Endpoint
Security's "a process just finished writing this file" - needs an Apple-granted
entitlement, is incompatible with the sandbox, and is not accepted on the Mac
App Store. There is no way to ask whether another process still holds a file
open either.

So it is a layered guess, and the layers are allowed to be wrong, because they
only decide **when to look**. Whether a look counts is decided afterwards by the
hash. A quiet period of ten seconds per file collapses one editing session's
burst of autosaves into a single version - ten is the number VS Code's own local
history uses, long enough to merge a burst and short enough that two deliberate
saves a minute apart stay two versions. Then a stability probe checks that size,
modification date and inode have all stopped moving; a zero-length guard catches
a truncating writer mid-flight; a quarantine check catches a download that has
not landed. Save a file without changing it and no version appears.

## When you would rather say when

![Retrace's snapshot panel over the app being worked in, naming the moment before it is taken](https://swiftfox.studio/retrace/listing/shot-5.jpg "The shortcut works from inside whatever you are in, which is the point: the moment worth marking is rarely one you were looking at Retrace for.")

Recording every save is right for a thesis folder and wrong for an
eighty-gigabyte render folder, so it is a setting on the folder rather than on
the app. A folder told to wait leaves the event stream but keeps its permission
open, so it can be walked the instant you ask - and everything one walk stores
shares a single instant, which is why a deliberate act arrives on the timeline
as one moment rather than as four hundred.

There are three ways to ask. The folder's own screen has a snapshot control, on
Cmd-S like a save. The Finder's History submenu offers **Take a Snapshot Now**.
And Ctrl-Opt-Cmd-S raises a small panel over whatever app you are in, takes a
name for the moment, captures every waiting folder and gets out of the way. Its
companion, Ctrl-Opt-Cmd-R, opens the history window: Retrace has no menu bar
item and no Dock icon, so a shortcut is the way back in. Both are rebindable in
Settings, and both carry three modifiers on purpose - a global registration that
loses a collision is told nothing by macOS, so a default's only defence is being
a combination nobody else reaches for.

Retention never thins a snapshot away on age. In a folder that only records when
asked, they are the only versions there are.

## Telling an overwrite from an edit

A file dragged onto another in Finder and a file saved by its own editor look
identical to every API macOS offers. Both leave a file at the path, both mint a
new inode - an atomic save renames a temp file over the target, and Finder's
Replace renames a copy over it in exactly the same way - and both arrive as the
same filesystem events. Nothing in the event says which one happened.

One thing separates them, and it is the file's own modification date. Bytes
written to a path carry the moment the event reported; bytes produced somewhere
else and moved there carry whatever date they had where they were written. So
the test is whether the bytes are older than the event that announced them, with
two minutes of slack - comfortably past the longest a large file can legitimately
be held back before it is captured.

That catches a Finder replace, an unzip landing on a document, `cp -p`, rsync, a
sync client writing the server's copy down, a restore from a backup. It does not
catch `cp` without `-p` or a browser download, both of which stamp the current
time, and it is deliberately left not catching them: every alternative - hashing
the previous bytes, diffing content, sniffing formats - costs orders of magnitude
more and is wrong in its own ways. Under-claiming is the right failure for a flag
that decides what gets kept.

It has one effect back on the ten-second window, too. A file that was placed does
not wait it out. The window exists to fold one file's burst of autosaves into a
single version, and a drop is not a burst - holding it there is exactly what lets
a second drop land on the first and the two be filed as one.

What you see: the folder list marks each folder with how many of its files
something was put on top of, the file list marks those rows and carries a switch
that narrows to them, and on the timeline the moment says the file was replaced
rather than edited. Retention takes it from there - the version underneath a
replacement is held for thirty days whatever else it thins away, because a
document written a year ago and buried this morning is exactly the copy somebody
opens this app to get back.

## Rewinding the folder, and undoing the rewind

![A folder's history in Retrace as a day-banded timeline, with each moment listing the files that changed in it](https://swiftfox.studio/retrace/listing/shot-2.jpg "Instants become moments, moments become sessions, and each one says what changed rather than only when.")

A busy folder produces hundreds of capture instants a day even after the merge
window has done its work, so the timeline folds them. Instants less than a
minute apart are one **moment** - saving four documents in the same half-minute
is one thing you did, not four - and moments more than 45 minutes apart start a
new **session**. Each moment lists the files that changed in it.

Rewinding takes the whole folder back to one of those moments. Every path is
vetted before anything is touched, because a plan half of which is allowed and
half refused must not run at all: you asked for a state, not for most of one.
Then the current state of everything the rewind will touch is captured, and that
step is the entire answer to "take me back to now again".

Both halves of that end up on the timeline. The act gets a row of its own saying
where it went - "you went back to 13:15" - and the state you left gets a point
just before it; neither folds into the work around it. When the rewind finishes
the way back is already selected, with its plan built, so "that was not it
either" is one press, and it is still there after the banner is gone or the app
has been relaunched. Undo is not a separate mechanism here, it is rewinding to
that point, and it is as undoable as anything else on the timeline. The row
whose state the folder currently holds is drawn differently rather than
labelled, so where you are now is something you see rather than work out, and
the first save afterwards moves it forward with the folder.

Files the rewind removes go to the Trash rather than being deleted, and so do
the folders its own removals emptied, deepest first, so a tree made since the
target collapses whole - one still holding something Retrace never captured
stays where it is, because a rewind must never take away what it could not put
back. A file that cannot be written does not abort the rest: the failures are
collected and named in the report. A rewind that silently did eleven of twelve
things is worse than one that says so.

## Putting one file back, after seeing what changed

![Two versions of a document compared side by side in Retrace, with the changed lines marked](https://swiftfox.studio/retrace/listing/shot-3.jpg "Text compares line by line, images compare by swipe or amplified difference, and a PDF just tells you which pages moved.")

Most recoveries are one file, and for those the folder is the wrong unit. Each
row says how many versions it holds and when it last changed, and right-clicking
one reaches the file itself - show it in the Finder, or open it. A single version
can be restored in place, or written beside the original as a numbered sibling if
you would rather compare them first. Restoring in place captures the current file
as a version before it overwrites anything, which is what makes the button safe
to press; the version the file already holds is not offered at all, it says so
instead.

Comparison is per format, because "what changed" has a different useful answer
in each. Text compares line by line. Images get a swipe divider, an onion-skin
crossfade, and a difference mode that amplifies and false-colors the result,
since a raw difference blend of two nearly identical images is a black frame
with a dot in it. A PDF is compared by hashing each page's text, which survives
the object reordering every re-export produces - a byte comparison would call
the whole file changed - and answers at the granularity people ask about, which
is "pages 3 and 7".

## What it deliberately does not do

It is **not a backup**. The history lives on the same disk as the folder, so a
failed drive takes both. That is the deliberate trade for capturing seconds
after a save rather than once an hour, and it is why Time Machine or an offsite
copy is still the other half.

There is **no sync, no iPhone app and no account**, and it works with the network
off. Files that live only in the cloud are skipped rather than downloaded, so
switching history on for a folder full of evicted placeholders cannot quietly
pull gigabytes back onto the disk.

Some trees are excluded by default: `node_modules`, `DerivedData` and `.build`
because they regenerate, `.git` and `.svn` because they are already a version
history, photo and video libraries because they are multi-gigabyte databases
that rewrite themselves constantly. Every default is visible and editable, since
the only thing worse than a bad exclusion is an invisible one.

History thins with age rather than growing forever: everything from the last 24
hours, hourly for a week, daily for a month, weekly for a year, over an
always-keep list - the ten newest versions of every file, anything starred, the
last version of a file that no longer exists, whatever an overwrite replaced for
thirty days after it, and the way back from a rewind for thirty days after that. A moment you give a name to is kept for good, and naming
one never erases what a rewind wrote there. Each folder has a disk budget, and
old versions retire against it.

## What it costs, and what else to look at

Retrace needs **macOS 14 or later**, runs on Apple Silicon and Intel, and takes
about 25 MB. It is a **one-time $8.99 purchase** with a 30-day trial that needs
no card and no email. The full specification is on
[the Retrace page](https://swiftfox.studio/apps/retrace).

If the question behind all this is which backup layer you are actually missing,
there is a survey in
[Time Machine alternatives for Mac](https://swiftfox.studio/blog/time-machine-alternatives-for-mac) -
version history and backup are different jobs and most people need both. And if
what is really wrong is that the disk is too full for any of it,
[Sweep](https://swiftfox.studio/apps/sweep) is the neighbor - it files a folder by rules you write, in
[sorting files automatically on a Mac](https://swiftfox.studio/handbook/auto-sort-files-on-mac), and the
space it frees up is in
[free up disk space on a Mac](https://swiftfox.studio/blog/free-up-disk-space-on-mac).