How to pause and resume hashing on Mac
A long hashing run is not an all-or-nothing commitment. Rocket Hash can stop mid-file and pick up from the exact byte it left off at, so needing the disk back for twenty minutes does not cost you the forty you have already spent — provided the file itself holds still while you are gone.
You set a 400 GB video archive hashing, and ten minutes in you need the disk back — or the laptop off the desk, or the fans to stop. The run is a quarter of the way into one enormous file, and you would rather not throw that quarter away.
You do not have to. A run in the Files tool can be paused while it is mid-file and then picked up from the exact byte it stopped at, which is a genuinely different thing from starting the file over. This page covers how that works, what a pause holds on to, and the one condition that quietly invalidates a resumed digest.
If the job has not started yet, hashing a very large file is the better place to begin, and the live throughput and time remaining will often tell you that you do not need to interrupt anything at all.
Pause, do the other thing, resume — the work carries on from the byte it stopped at instead of starting the file again. The one thing you must not allow is for the file itself to change while you are away.
Why a hash can be paused at all
A hash function never looks at a whole file. SHA-256 works through it in 64-byte blocks, and the only thing it carries from one block to the next is 32 bytes of internal state. SHA-512 uses 128-byte blocks and 64 bytes of state. Either way, the amount of information that represents “where I am” is measured in tens of bytes, not gigabytes.
That is the whole trick. Your position in a file being hashed is the internal state, the byte offset, and the running count of how much has gone in — SHA-2 mixes that length into the very last block as part of its padding, which is why the total matters and not just the bytes. Keep those three things and you can stop reading, come back, and continue as if nothing happened. The digest you get at the end is identical to the one an uninterrupted run would have produced.
The flip side is the reason a pause is worth having. Block nine hundred thousand cannot be processed before the one in front of it has been, so a single file's digest cannot be split across eight cores and cannot be started in the middle. SHA-3 is built from a sponge rather than a chain, and it is just as sequential. Without a resume, the only way to finish a file you interrupted is to read all of it again.
Pause a run and pick it up again
-
Start the run
In the Files tool, drag the file or folder in, or use the add button in the toolbar. The Algorithm control, marked with a #, decides which digest each row shows you and which one an export carries. All eight are computed whatever it is set to, out of a single read of the file.
-
Pause it mid-file
Pause the run while the file is still streaming. The read stops where it is rather than unwinding, nothing is discarded, and — as with every part of hashing — nothing is written to the file you were reading. Files that have already finished keep the digests they produced.
-
Do the other thing
A paused run is not reading, so the disk, the bus and the CPU are yours again. It is not sitting on your memory either: the footprint stays flat at roughly 16 MB whether the file in front of it is 4 MB or 400 GB, because the bytes pass through rather than piling up.
-
Resume from the same byte
Resume, and the work continues from the offset it stopped at rather than from zero — on a large file that is the difference between a few seconds and another twenty minutes. Any estimate of time remaining is an average over recent progress, so give it a moment after a resume before you read anything into it.
What survives a pause and what does not
| Thing | What happens to it |
|---|---|
| Your position in the current file | Kept. The resume continues from that byte. |
| Digests of files that already finished | Already computed. A pause has nothing to take away from them. |
| The queue of files still waiting | Still queued. Pausing stops the work, not the list. |
| A “partial digest” for the part that is done | Does not exist in any usable form. There is internal state, but no value you could publish or compare. |
| The file on disk | Untouched. Hashing is a read from the first byte to the last and back out again. |
| Exclusive use of the file | Never had it. A pause does not lock anything, and nothing stops another program writing to the file while you are away. |
That last row is the one that bites, and the next section is about it.
If the file changes while you are paused
Hash the first half of yesterday's file and the second half of today's and you get a perfectly valid-looking 64-character digest for a file that has never existed. Nothing can detect that from the inside, because from the inside it is simply more bytes.
So pausing is safe over a finished file and unsafe over a moving one. A download still in progress, a log something is appending to, a video being rendered, an open database, a folder a sync client is reconciling — all of those can change under a paused run, and the result is a digest that matches nothing and cannot be explained later. Hashing a file that is still being written goes through how to tell, and what to do with files that genuinely never hold still.
The same caution covers the volume rather than the file. If the bytes live on a USB disk or a network share, a paused run is waiting on a volume that has to still be mounted when you come back; hashing files on an external drive covers what happens when it is not.
Pause versus stopping the run
They are different intentions and it is worth being clear which one you have. Pausing means you are coming back to this file. Stopping ends the run cleanly — the work that finished stays finished, and the file you were part way through is simply not done. The reset button in the toolbar is a third thing again, for when you are finished with this batch entirely.
If you stop a long run part way and the results matter, write them down before you clear anything. The export button turns what is on screen into a shasum-compatible manifest, which is a file rather than a window, and a file is what you can come back to next week — see exporting a checksum manifest for the format and what to do with it.
Planning a run you know you will interrupt
Some jobs are long enough that an interruption is not a risk but a certainty. Three things make those easier.
- Stop the Mac sleeping. Sleep is an interruption nobody chose, and it is the most common reason a run that should have taken forty minutes is still unfinished in the morning. Keep the machine awake and plugged in for anything measured in hours.
- Ask for what you need in one go. Because the read happens once regardless, adding algorithms costs arithmetic rather than another trip across the disk. Going back for a second digest tomorrow costs a whole second read of the file, which on 400 GB is the expensive half.
- Export as you go. On a queue of tens of thousands of files — and six figures is within range — the durable artifact is the manifest, not the run. Hashing many files at once covers how the status bar counts a queue that size.
Troubleshooting
The digest after a resume does not match the published one
Check whether the file could have changed while you were paused, because that is the failure mode unique to a resumed run and it produces exactly this symptom. If the file was definitely static, the cause is one of the ordinary ones — a partial download, the wrong build, a different algorithm — and what to do when a checksum does not match sorts them, commonest first. The quickest way to settle it either way is to run the file again, uninterrupted, and see whether the answer is stable.
The Mac went to sleep in the middle of a long run
Sleep stops the work without asking and may also drop an external volume on the way down, which is a worse starting point than a pause you chose. Treat a run that slept through the night as unproven rather than finished: restart the file in question, and this time keep the display awake and the power connected.
The drive was unplugged while the run was paused
A byte offset only helps if the bytes are still reachable. Reconnect the volume, confirm the file is there and the same size, and hash it again from the beginning. It is an annoying outcome, not a dangerous one — nothing was written, so nothing was damaged.
I need the CPU back, not just the disk
Pausing gives you both, since a paused run is doing no arithmetic and issuing no reads. If the machine still feels slow afterwards, hashing was probably not what was loading it: at roughly 2 GB/s for SHA-256 on Apple Silicon, a single stream is usually waiting on the disk rather than saturating a core. Why hashing is slow has the one-minute test for which part of the machine is actually busy.
The time remaining looks wrong straight after a resume
An estimate needs recent history to be worth anything, and a resume throws that history away: the first figure after one is extrapolated from a second or two of reading. Wait five or ten seconds and it settles on the real rate. It is the one number on screen a pause genuinely degrades — the byte offset and the finished digests are exact either side of an interruption.
Frequently asked questions
Does pausing a hash lose the work already done?
No. A pause keeps your position in the file being read, so resuming continues from that byte instead of starting the file again. Files earlier in the queue that already finished are finished — their digests were computed as they streamed past and a pause has nothing to take back.
Can I quit the app and carry on the hash tomorrow?
Plan on no. A pause holds your place in the run in front of you; it is not a document you reopen next week. If a job is long enough that you might reboot in the middle of it, the thing to make durable is the finished work — export a manifest of the files that completed, then start a fresh run on what is left.
What happens if the file changes while the hash is paused?
You get a digest that describes no real file: the first part of the old version and the rest of the new one, combined into a value that will never match anything. No tool can detect this, because from inside the calculation it is just more bytes. Never pause a run over a download in progress, an open database or a log something is appending to.
Why can't hashing just use all my CPU cores to finish faster?
Because a hash is a chain. Each 64-byte block of SHA-256 is processed using the internal state left by the block before it, so there is no way to compute the middle of a file without having computed the start. That is a property of the algorithm rather than a limitation of any particular tool, and it is exactly why resuming from a byte offset is worth having.
Is it safe to pause a hash on an external drive and unplug it?
No. Resuming means reading from the same byte of the same file, which requires the volume to still be mounted when you come back. Unplug it and you are starting that file over. Eject properly, reconnect, and rerun rather than assuming the offset still means something.
Can I get a checksum for just the part of the file that finished?
Not in any usable sense. There is internal state part way through, but it is not a digest you could publish or compare with anything — and a digest of the first 40% of a file would only be comparable with another tool's digest of exactly the same 40%, which nobody publishes. Finish the file or start it again.
Does pausing and resuming give a different digest than a single run?
No, as long as the file did not change. The interrupted run resumes with the same internal state and the same running byte count it stopped with, so the final value is bit-for-bit what an uninterrupted pass would have produced. That is worth verifying once on a small file if you are about to rely on it.