Manage files and folders in Mac: the rules underneath

Most advice on this subject is about taste. Where should projects live, how deep should folders go, tags or no tags. Taste matters, but it is not what breaks a working system. Systems break when the machine does something the person did not expect: a file that was there yesterday is gone after a copy, a coloured tag disappears after a file is sent to a colleague, two documents refuse to sit in the same folder even though their names look different on screen. None of that is a matter of preference. It is macOS applying rules that are rarely written down in the same place. Knowing those rules changes which schemes are worth building and which will quietly fall apart.

Two layers, and only one of them is a choice

Any arrangement of files sits on two layers. The upper layer is chosen: the folder tree, the naming convention, whether the Desktop is a workspace or a dumping ground. Almost every article about this subject stops there. The lower layer is not chosen. It decides what a filename is permitted to contain, what happens to the second file when two names collide, whether the operation just performed was atomic or a copy followed by a delete, and which of the information attached to a file travels with it.

The reason the lower layer matters is that its failures are silent. A scheme that violates it does not produce an error the first time. It produces a slow accumulation of small losses that get blamed on the person. Tags that were carefully applied last year are missing from half the archive. A folder that was copied to a drive and back has fewer items than it started with. The convention was fine. The convention just relied on something the system does not guarantee.

There is also a third-party version of this problem. Finder is not an application in the ordinary sense. It cannot be quit, it starts with the session and stays for its duration, and its defaults are therefore the defaults for the whole machine. Any habit built on Finder behaviour is built on a process that is always running and always applying the same rules. That is an argument for learning the rules rather than working around them one folder at a time.

What a name is allowed to be

Apple states the limits for names typed into Finder plainly: numbers and most symbols are allowed, a colon is not, and a name cannot begin with a period. The length limit is 255 characters, and it is characters rather than bytes. A name of 255 Japanese characters is accepted on an APFS volume and a name of 256 is refused, which means the practical ceiling is the same whichever script the name is written in.

Two of those rules have consequences worth planning around.

The leading period is the hiding mechanism, not a style choice. Anything named .notes is invisible in Finder until Command-Shift-Period is pressed, and it stays invisible in most Open and Save dialogs. Files that arrive from a repository or an archive frequently carry such names, which is why a folder can look empty in Finder and contain a dozen items in the shell.

The colon restriction is enforced by Finder, not by the filesystem. Running touch "a:b.txt" in Terminal creates the file without complaint. Names like that survive on the local disk and then cause trouble on the way out, in archives, on network shares, and on other operating systems. If a naming convention is generated by a script rather than typed by a person, the colon is the character to strip first.

The rule that surprises people most is that the default macOS volume does not distinguish upper case from lower case. Creating Foo.txt and then foo.txt in the same folder leaves one file, not two. On a case-sensitive volume, or in an archive built on Linux, both can exist. Copy that folder onto a normal Mac and one of them silently wins. Any convention that relies on capitalisation to carry meaning, such as README.md next to Readme.md, is a convention that will lose data in transit.

A move is not always a move

Dragging a folder from one place to another looks like a single operation. Underneath, it is two different operations depending on where the destination is.

Within one volume, a move is a rename. The file's identity does not change, so ls -i reports the same inode number before and after, and the operation completes in the same time whether the file is 4 kilobytes or 40 gigabytes. Nothing is copied, so nothing can be half copied.

Across volumes, the same gesture is a copy followed by a delete. The manual page for mv on macOS says so directly: because the rename system call does not work across file systems, the command falls back to cp and rm. The consequences follow from that. The time is proportional to the size. An interrupted transfer can leave a partial file at the destination that looks complete in a listing. The original is only removed after the copy reports success, which is the one piece of good news in the arrangement.

External drives add their own limit, and it is one people hit while trying to make a backup.

Make sure the external drive is formatted as APFS, Mac OS Extended, or exFAT. NTFS drives are read-only on Mac, so you can't move files to them. Source: support.apple.com

The practical rule that falls out of all this: for anything large or irreplaceable crossing a volume boundary, copy first, confirm the destination, then delete the source as a separate decision. Treating it as one gesture is what turns a cable being knocked out into a lost folder.

The information attached to a file, and where it falls off

A file on macOS is more than its contents. Finder tags, Finder comments, the quarantine flag on downloads, and several other pieces of information live in extended attributes, stored beside the data rather than inside it. They are visible with ls -l@ and listed in full with xattr -l. A file tagged in Finder shows an attribute named com.apple.metadata:_kMDItemUserTags.

Whether that information survives an operation depends entirely on which operation it was.

Operation	Extended attributes	Notes
cp with no options	Preserved	The default behaviour keeps them
cp -X	Stripped	The flag exists specifically to drop them
ditto	Preserved	Designed to copy Mac metadata faithfully
zip then unzip in Terminal	Lost	Tags are gone after the round trip
Upload to a web service	Lost	Only the byte stream is transmitted

The last two rows are the ones that decide whether a tagging habit is worth forming. Tags are excellent while a file stays on the machine that applied them. They do not cross a plain archive, they do not cross a browser upload, and they do not reliably cross a share with someone else. A filename, by contrast, crosses everything. That is the argument for putting the information that must survive into the name, and using tags for the temporary state that only matters locally, such as what still needs review this week.

There is a matching argument on the other side. Names cannot be searched by meaning, and a name that carries five pieces of information becomes unreadable. The split that holds up is: identity in the name, status in the tags, and no scheme that depends on tags being present a year later.

Things that are not where they appear to be

Three cases regularly break the assumption that a listing shows what is on the disk.

The first is iCloud Drive. With Desktop and Documents stored in iCloud and optimised storage enabled, items appear in Finder with a status indicator and no local copy. They are searchable, they have names and sizes, and the bytes are elsewhere until something asks for them. Any script that walks a folder and reads every file will trigger downloads, which is why an innocuous grep -r over the Documents folder can pull gigabytes across the network.

The second is symbolic links. A link made with ln -s records a path and nothing more. Rename the target and the link points at a name that no longer exists. Finder's Make Alias produces a different kind of object with different behaviour, so the two are not interchangeable even though both show up as a small file in a listing. Tools that walk folders treat them differently as well, and most offer a flag to follow links or leave them alone.

The third is permissions. A folder that the current user cannot read appears in a listing as an entry with no contents rather than as an error, depending on the tool. Comparisons and backups run over such a folder report it as empty, which looks like success.

None of these is a defect. All three mean the same thing in practice: before trusting a count of files, confirm that the tool was allowed to see all of them, and that the ones it saw were actually present rather than referenced.

The cost that does not show up in any of these rules

Everything above is about the machine's behaviour. There is a separate cost that no setting addresses, and for anyone who works with folders and a command line together it is usually the larger one.

Managing files at any serious volume means moving between a folder view, a shell, and increasingly a chat window holding an assistant. The folder view is where things are found and selected. The shell is where operations that Finder cannot express are run. The assistant is where the operation is worked out before it is run. Each of those is a separate window, and the state does not travel between them. A selection of fourteen files made by eye in a folder view cannot be handed to a shell; it has to be rebuilt as a pattern. The result of a command cannot be seen in the folder view without switching back and refreshing.

That is a tooling question rather than an organising question, and it is the one worth measuring before redesigning a folder tree. The category of tool that addresses it puts the folder view and the command line in the same window, and the more recent ones add the assistant as a third pane. A side by side look at what the alternatives do differently is more useful here than a feature list, because the differences that matter are about layout rather than capability. The full set of capabilities is worth reading with one question in mind: how many of the daily round trips does it remove.

What to change first

Start with the rules that cost data rather than time. Stop relying on capitalisation to distinguish names, move anything that must survive an archive out of tags and into filenames, and split every cross-volume move into a copy, a check, and a delete. Once the losses stop, count the window switches in a normal hour of work, and if that number is the real cost, look at a single window that holds the folders, the terminal, and the assistant together, which is the shape Atriens is built in.