Organizing an external drive: the setup order that holds up

Organising an external drive rarely fails in the middle. It fails at the start, where dragging begins before anything has been decided, and at the end, where nobody can say which folders were already moved. The fix is a fixed order: decide four things, check the destination, copy with a command chosen for what it preserves, verify, then delete. The results below come from tests run on macOS 26 against APFS and exFAT volumes, because the choice of copy command changes what arrives at the other end in ways that are invisible in Finder.

Four decisions before anything moves

Each of these takes a couple of minutes. Skipping them costs a redo.

The role of the drive. Archive, working scratch, or backup target. A drive carrying all three roles loses all three at once when the hardware fails, which is the failure mode a backup was meant to cover.

The top level split. By year, by project, or by type. All three can work. The correct one is whichever gets recalled first when looking for something. Project names come to mind first in client work; dates come first in production archives. With no clear answer, year is the safer default, because it makes retiring old material a single move.

The depth limit. Three levels from the root is enough for almost everything. A limit prevents the miscellaneous folder that absorbs anything ambiguous and never gets opened again.

The naming pattern. Date first or date last, underscore or hyphen. The specific pattern matters far less than picking one and not changing it halfway through, because inconsistent names defeat sorting and defeat search at the same time.

Write those four decisions into a plain text file at the root of the drive. Six months later the reasoning behind the structure is gone, and without a written rule every ambiguous file invents a new one.

Decide what is not going at all

A transfer list assembled without a filter tends to include everything that happens to be sitting in the source folder, and a surprising share of it should not be archived anywhere.

Three categories are worth pulling out before the copy starts. Anything a tool regenerates automatically, such as caches, render intermediates, and build output, costs storage and buys nothing, since it will be rebuilt on demand and will be stale by the time it is needed. Anything still downloadable from its original source is re-obtainable at the cost of bandwidth, and only worth archiving if the source is likely to disappear. Anything that exists in a second location already does not need a third.

What remains is the material that exists once and cannot be produced again, which is both the smallest category and the only one that justifies the effort. Filtering first tends to shrink a transfer considerably, and a smaller transfer finishes in one session instead of three.

The filtering pass is also the right moment to notice folders that are large for a reason nobody remembers. Sorting the source by size before copying surfaces those in a few seconds, and each one is a decision made now rather than a decision deferred onto a drive where it will be harder to see.

Check the destination format before copying

An older drive is often still carrying whatever format it shipped with, which may not suit what is about to be put on it.

diskutil info /Volumes/VOLUME_NAME | grep "File System Personality"

The answer comes back as APFS, ExFAT, MS-DOS (FAT32), or similar. Apple documents APFS as the default file system for Macs since macOS 10.13, with native encryption, space sharing, and snapshots. For a drive that never leaves the Mac, that default is the path of least friction.

The reason to check now rather than later is that changing a format erases the volume. There is no conversion that keeps the contents in place. Discovering the mismatch after copying 400 GB means evacuating the drive and doing the whole transfer twice. Any drive still formatted as FAT32 also carries a per file size limit that large video and disk image files will hit, and finding that out during the copy is worse than finding it out now.

Deal with duplicates after the copy, not during

Copying while deciding which of three similar files is the current one turns a mechanical task into a judgement task, and judgement tasks do not survive being interrupted.

Copy everything first. Verify. Then resolve duplicates on the destination, where two things help: the originals still exist, so a wrong call is recoverable, and similar files now sit next to each other instead of being scattered across four source folders.

When comparing, do not treat same name plus same size as proof of identity. Files re-exported with different settings frequently match on both. Compare contents with a checksum when the answer matters.

The copy command decides what survives

This is the part that gets skipped, and it is the part that quietly loses metadata. The same file was copied by each of the usual methods on macOS 26, then inspected for modification date and extended attributes.

Method	Modification date	Tags and extended attributes
cp	reset to the time of the copy	preserved
cp -p	preserved	preserved
ditto	preserved	preserved
rsync -a	preserved	dropped
rsync -aE	preserved	preserved
mv to another volume	preserved	preserved

A file dated 2020 kept that date through cp -p and arrived stamped with the current time through plain cp. On an archive drive, that difference destroys chronological sorting across the entire transfer, which is often the only remaining way to find old material.

The rsync -a row is the one that surprises people. Tags applied for classification were simply not present on the destination copy. Adding -E brings them across.

The rsync on macOS is not the rsync in most guides

The rsync that ships with macOS 26 is openrsync. Asking it for its version returns protocol version 29, described as compatible with rsync 2.6.9.

The practical consequence is that rsync -aX, which appears in most guides as the way to carry extended attributes, does not run. It stops with invalid option -- X. On macOS the equivalent is -E, or the long form --extended-attributes. Any procedure copied from a Linux oriented guide will fail at exactly this line.

--progress does work, with one caveat: non-ASCII file names print as escaped octal sequences, so a Japanese folder tree scrolls past as unreadable output. Progress is still legible as transferred volume, just not as file names.

When none of this needs to be remembered, ditto is the easier choice. It carries extended attributes, access control lists, and resource forks by default, so nothing is lost to a forgotten flag.

Measure, copy, verify, delete

Keep those four in order. Reversing the last two removes the originals before anything has confirmed the copy.

Measure the source first and write the numbers down:

find SOURCE_FOLDER -type f | wc -l
du -sh SOURCE_FOLDER

Copy with the method chosen above, and leave the originals alone.

Verify by measuring the destination the same way and comparing. Two things commonly explain a mismatch. Hidden files count, because find includes names beginning with a dot, and a destination that cannot store extended attributes natively gains a hidden companion file for each item, which inflates the count on one side only. For files that genuinely matter, compare contents:

shasum -a 256 SOURCE_FILE
shasum -a 256 DESTINATION_FILE

Sizes will not match exactly even when everything is correct, because allocation differs between formats and the gap widens with many small files. Treat the item count as the figure to reconcile and the byte total as a sanity check.

Delete last, and remember that deleting on the external volume moves data to a hidden Trash folder on that same volume. Free space does not change until the Trash is emptied.

Make it survivable across sessions

A multi hundred gigabyte move does not finish in one sitting. Something will interrupt it.

Both ditto and rsync can be run again over the same destination. rsync --partial keeps partially transferred files so the next run resumes rather than restarts. A Finder drag that stops halfway leaves no record of how far it got, which is why command line copying wins on large jobs even for people who prefer the window.

Splitting the job helps more than any flag. Copy one top level folder at a time and log each completion in a text file, one line holding the date, the folder, and whether it was verified. That file is what makes tomorrow's session start in the right place.

Two smaller points. Sleep can interrupt a long transfer, and prefixing a command with caffeinate suppresses sleep only for the duration of that command, which avoids changing a system setting and forgetting to change it back. And do not run other heavy work against the same drive during a transfer, because the two jobs share one connection and both get slower while the progress figures become meaningless.

Leave an index behind

An external drive spends most of its life disconnected, so finish by writing down what is on it.

find /Volumes/VOLUME_NAME -maxdepth 2 > ~/Documents/drive-index.txt

Two levels is enough to jog memory without producing thousands of lines. Kept on the internal disk, it answers which drive holds what without plugging anything in. Put the date and the volume name on the first line, and the volume identifier from diskutil info alongside it once there is more than one drive to tell apart.

The index is also what makes the next pass cheap. Regenerate it whenever the drive is written to, overwriting the previous version, and the file stays a current answer rather than an archaeological record. A stale index is worse than none, because it gets trusted.

One more habit pays off disproportionately. Set a reminder to open the drive once every few months, confirm it still mounts, and open two or three files at random from different folders. Drives that sit in a drawer for two years sometimes fail to spin up, and finding that out during a quiet check is a different experience from finding it out on the day the material is needed. The check takes two minutes and needs no software.

Rename before copying, never after. Renaming files that documents and projects already reference breaks those references, and doing it after the move breaks them a second time.

What to change first

Look back at the order above and count the surfaces: a terminal to measure and copy, a folder window to decide destinations, a text editor to keep the log. Every folder in the list goes around that loop once.

Count the switches on the next transfer before changing any tool, because that number identifies the real bottleneck. It is the axis behind the comparison with other file managers and the capabilities listed under Features, and the questions that come up while setting this up are collected in the FAQ. Atriens puts the measuring and the moving in one place.