Dateien am Mac umbenennen, ohne etwas zu überschreiben

Damit beim Umbenennen am Mac nichts überschrieben wird, muss der Vorgang abbrechen, sobald der neue Name vergeben ist. Namen, die voneinander abhängen, brauchen außerdem einen Zwischenschritt. mv übernimmt von sich aus keins von beidem. mv a.txt b.txt ersetzt eine vorhandene b.txt ohne Rückfrage, und die alte Datei liegt danach auch nicht im Papierkorb.

Der kleinste Unglücksfall: zwei Namen tauschen

Du hast zwei Dateien vertauscht benannt und willst das korrigieren. Der naheliegende Versuch sieht so aus:

mv a.txt b.txt
mv b.txt a.txt

Im Test unter macOS 27.2 blieb danach genau eine Datei übrig, a.txt mit dem alten Inhalt von a.txt. Der Inhalt von b.txt war weg. Tauschen geht nur über einen dritten Namen:

mv -n a.txt tausch.tmp
mv -n b.txt a.txt
mv -n tausch.tmp b.txt

Das -n verhindert das Ersetzen, meldet es aber nicht. Auf demselben Mac übersprang mv -n eine belegte Zieldatei ohne Meldung und beendete sich trotzdem mit Status 0. Ein && zwischen den Zeilen fängt das also nicht ab. Schau dir das Ergebnis deshalb mit ls an.

Bei einer durchnummerierten Fotoserie reicht die richtige Reihenfolge. Sollen alle Nummern um eins steigen, fängst du hinten an, damit jede Datei auf einen freien Namen trifft:

for i in 3 2 1; do mv -n IMG_$i.jpg IMG_$((i+1)).jpg; done

Wann zwei Namen derselbe Name sind

Für den Mac sind Müller.pdf und MÜLLER.pdf auf einem normalen Laufwerk dieselbe Datei. Apples APFS-FAQ nennt die Variante ohne Unterscheidung von Groß- und Kleinschreibung den Standard auf macOS.

Bei Umlauten kommt etwas dazu, das man keinem Namen ansieht. Ein ü lässt sich als ein Zeichen speichern oder als u mit nachgestellten Punkten. Laut derselben FAQ können beide Schreibweisen nicht nebeneinander im selben Ordner liegen. Im Test fand der Mac die Datei unter beiden Formen, und beim Schreiben unter der zweiten Form blieb es bei einer Datei.

Daraus ergeben sich zwei Stolperstellen. Eine reine Änderung der Schreibweise scheitert mit mv -n, denn mv -n Hello.txt hello.txt tat im Test nichts und meldete trotzdem Erfolg. Ohne -n klappte es. Und ein Skript, das Namen als Text vergleicht, hält zwei Schreibweisen eines Namens für verschieden, obwohl das Dateisystem darin eine einzige Datei sieht.

Was Namesmith prüft, bevor sich etwas bewegt

Namesmith ist unser Programm zum Umbenennen ganzer Dateilisten. Für diesen Artikel habe ich den Quellcode gelesen, vor allem Engine.swift und Renamer.swift, und beide Dateien in einem kleinen Testprogramm laufen lassen.

Die Vorschau vergleicht Namen so, wie es das Dateisystem tut, also nach Unicode-Normalisierung und in Kleinbuchstaben. Bild und BILD in derselben Liste werden deshalb zu Bild.jpg und BILD (2).jpg. Das gilt auch auf Laufwerken mit Unterscheidung von Groß- und Kleinschreibung, wo beide Namen möglich wären. Dort ist Namesmith strenger als nötig.

Namen von Dateien, die selbst in der Liste stehen, gelten als frei, weil diese Dateien ja gleich umziehen. Deshalb ist ein Tausch kein Konflikt. Namen anderer Dateien im Ordner bleiben belegt.

Schwieriger sind Ketten. Angenommen, a.txt soll b.txt heißen, b.txt soll c.txt heißen und c.txt soll d.txt heißen, und eine d.txt außerhalb der Liste gibt es schon. Die Standardeinstellung "Add a number" hängt eine Nummer an, und aus c.txt wird d (2).txt. Mit "Don't rename" bleibt c.txt liegen. Damit ist ihr Name weiter belegt, also kann b.txt nicht dorthin, und a.txt hängt ebenfalls fest. Die Prüfung beginnt nach jeder ausgeschlossenen Datei von vorn, bis sich nichts mehr ändert. Im Test standen am Ende alle drei Zeilen auf Konflikt.

Zwei Durchgänge statt einer Reihenfolge

Beim eigentlichen Umbenennen sucht Namesmith keine clevere Reihenfolge. Im ersten Durchgang bekommt jede Datei einen versteckten, eindeutigen Namen im selben Ordner, der mit .fastrenamer- beginnt, einem Rest des früheren Arbeitstitels. Im zweiten Durchgang wandert sie zum endgültigen Namen. Nach dem ersten Durchgang sind alle alten Namen frei. Tausch, Ringtausch über drei Dateien und die verschobene Serie kamen im Test mit dem richtigen Inhalt unter dem richtigen Namen heraus. Liegen Einträge in verschiedenen Ordnertiefen, laufen beide Durchgänge je Tiefe, von innen nach außen, damit die Pfade der Dateien darin gültig bleiben.

Beide Durchgänge nutzen renamex_np mit dem Schalter RENAME_EXCL. Laut man 2 rename liefert der Aufruf EEXIST, wenn das Ziel schon existiert. Die Prüfung steckt also im Umbenennen selbst, und es gibt keine Lücke, in der ein anderes Programm die Datei anlegen könnte. Der Versuch, a.txt auf eine vorhandene b.txt zu legen, endete im Test mit einer Fehlermeldung, und beide Dateien blieben unverändert.

SD-Karte und USB-Stick: hier geht es nicht

Die Handbuchseite schränkt den Schalter ein, er wirkt nur auf Dateisystemen, die ihn unterstützen. Auf Testlaufwerken mit exFAT und FAT brach unter macOS 27.2 jede Umbenennung mit "Operation not supported" ab. Es ging nichts verloren, aber es wurde auch nichts umbenannt, und der Code sieht keinen anderen Weg vor.

Liegen deine Fotos auf einer Karte oder einem Stick in einem dieser Formate, kopierst du sie also zuerst auf das Laufwerk des Macs, benennst sie dort um und kopierst sie zurück. Mit APFS gab es im Test keine Probleme, weder mit noch ohne Unterscheidung von Groß- und Kleinschreibung. Netzlaufwerke habe ich nicht getestet.

Abbruch mitten im Vorgang

Den Verlauf für das Rückgängigmachen schreibt Namesmith erst, wenn die ganze Liste durch ist, und während des Laufs hält nichts auf dem Laufwerk die alten Namen fest. Ein Abbruch kann also an jeder Stelle des Laufs Dateien zurücklassen. Im Testprogramm habe ich eine Liste mit 60.000 kleinen Dateien nach 0,8 Sekunden mit kill -9 beendet, noch im ersten Durchgang. Danach lagen 2.320 Dateien unter versteckten Namen und 57.680 unter den alten. Ein Abbruch im zweiten Durchgang hinterließ 53.422 versteckte und 6.578 neu benannte Dateien.

Der Inhalt jeder Datei war noch da, weil Umbenennen nur den Ordnereintrag ändert. Die alten Namen der versteckten Dateien sind aber verloren, im Verlauf steht nichts über diesen Lauf, und im Code habe ich nichts gefunden, das sie beim nächsten Start zurückholt. Sie können auch in Unterordnern liegen. In einem Test über drei Ordnerebenen war beim Abbruch die tiefste fertig, die mittlere im ersten Durchgang und die oberste unberührt. find . -name '.fastrenamer-*' findet sie auf jeder Ebene.

Der Lauf selbst ist kurz. 10.000 leere Dateien brauchten auf einem M3 Pro für beide Durchgänge zusammen 1,45 Sekunden, die 60.000 Testdateien ohne Abbruch 11 Sekunden. Nach einem abgeschlossenen Lauf kannst du die letzten 50 Listen einzeln rückgängig machen, auch nach einem Neustart. Geht es dir eher darum, zwei Ordner gleich zu halten, lies Ordner abgleichen, ohne dabei Dateien zu verlieren.

Lade die Demo von der Namesmith-Seite und zieh eine durchnummerierte Serie hinein. Baue die Schritte auf und achte darauf, welche Zeilen die Vorschau als nummeriert oder als Konflikt markiert. Die Demo läuft ohne Zeitgrenze und zeigt die volle Vorschau, das Umbenennen selbst geht mit Lizenz. Namesmith braucht macOS 14 oder neuer auf Apple Silicon.