Kleines Copy / Paste Snippet um einen gesamten Mac (oder ein Linux) in ein beliebiges Zielverzeichnis auf einen anderen Rechner zu übertragen. Zuerst wird ins Root-Directory ” / ” gewechselt und von dort aus relativ in das entfernte Zielverzeichnis übertragen. Da dieses sehr wahrscheinlich etwas länger dauert, habe ich dem “rsync” ein “nohup” vorgeschaltet. Hierdurch kann man den laufenden Befehl mit der Tastenkombination Ctrl-z anhalten und anschliessend mit ” bg ” als Hintergrundprozess weiterlaufen lassen und das Terminal schliessen. Evtl. Fehler kann man später dann in der Datei ” nohup.out ” nachlesen.

cd /
nohup rsync \
 --relative \
 --archive \
 --executability \
 --compress \
 --exclude=/Volumes/* \
  . <user>@<zielrechner>:/<zielpfad>

Terminal Befehl gleich mit Copy/Paste übernehmen.

/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister \
-kill \
-r \
-domain local \
-domain system \
-domain user

Als Anwort bekommt man die wenig ausdrucksstarke Meldung:
ThrottleProcessIO: throttling disk i/o
Wieso für das Entfernen ungültiger Einträge der Disk I/O gedrosselt wird, wissen anscheinend nur die “Apfel-Leute”, aber mir soll’s recht sein.


Zugegeben, TimeMachine Backups über SMB-Mounts werden offiziell nicht von Apple unterstützt. Daher hilft bei auftretenden Problemen alles jammern nicht, Lösungen müssen her. Immer wieder kann es vor allem bei zu kurzem Sicherungs-Intervall bzw. Unterbrechungen bei den Sicherungen zu einer Korruption des Sparsebundles kommen. Der Sicherungs-Intervall lässt sich sehr komfortabel mit der Freeware TimemachineEditor vergrößern, mir persönlich  reicht 1 Backup / Tag.

Sollte die TimeMachine die Sicherung aufgrund eines Fehlers ablehnen, sind Reparaturmaßnahmen erforderlich.

Vor der Aktion mit dem Festplatten-Dienstprogramm weiter unten sollte man das Sparsebundle komprimieren und optimieren. Hierzu kommt der Terminal-Befehl hdiutil compact zum Einsatz. Wichtig dabei: Das Volume innerhalb des Sparsebundles darf nicht gemountet sein, ist also mit “xxxx auswerfen” über den Finder zu entfernen.

Copy/Paste Befehl:

hdiutil compact \
 -batteryallowed \
 -sleepallowed \
 -verbose \
 /Volumes/TimeMachine/xxxxx.sparsebundle

Hat die Optimierung geklappt folgt ein Reparaturversuch mit dem Festplatten-Dienstprogramm. Hierzu ist das Verzeichnis, welches das Sparsebundle enthält, einfach per Finder zu verbinden, sodass das Volume es im Festplatten-Dienstprogramm erscheint. das sparsebundle links in der Liste selektieren und den Button ” Volume reparieren ” anklicken. ” Volume überprüfen ” kann man sich schenken.

Weitere Infos:

Leider kommt es trotz aller Maßnahmen zu irreparablen Sparsebundles. Daher bin ich nun dazu übergegangen, das sparsebundle via ROBOCOPY mithilfe eines geplanten Tasks auf eine externe USB-Disk zu sichern. Das geht sehr schnell und hat mich mittlerweile auch schon so manches Mal davor bewahrt eine vollständig neue TimeMachine aufzusetzten.


Als alter Unixer läuft bei mir stets ein Terminal mit “tail -f /var/log/system.log“. Mein AppleScript Projekt …. schreibt zu Kontrollzwecken über den logger Befehl ebenfalls in dieses Logfile. Aufgrund eines Progammfehlers lief das Script nicht mehr, aber in der System.log taucht jedesmal folgende Zeile auf:

...
/System/Library/CoreServices/AppleScript Runner.app/
Contents/MacOS/AppleScript Runner[3844]: CPSGetFrontProcess():
This call is deprecated and should not be called anymore.
...

Selbstverständlich suchte ich die Ursache dafür in meinem Code, konnte aber nichts finden. Und CPSGetFrontProcess() sagte mir nun rein gar nichs. Die Meldung erschien jedesmal, wenn ein Script als Ordneraktion ausgeführt wurde, im AppleScript Editor ausgeführt erschien sie nicht. Also googelte ich um Hilfe und wurde auch an diversen Stellen fündig. Offensichtlich schleift MacOSX diese Meldung schon seit eingien Jahren mit sich herum. Es ist ein Hinweis für die Entwicker des AppleScript Runners, also dem Stück Software, welches die Scripte laufen lässt. Darin wird anscheinend immer noch die Funktion CPSGetFrontProcess() benutzt, obwohl sie nicht mehr verwendet werden sollte. Es ist also eine Meldung, für die man selbst keine Schuld hat, sie aber auch nicht abstellen kann. Das wollte ich testen und habe einfach mal ein paar Orginal-AppleScripte als Ordneraktion angehängt. Und tatsächlich werden auch hiermit diese Meldungen ins system.log geschrieben. Man müsste mal hochrechnen, wie viele Macs weltweit im Einsatz sind und wie viele davon AppleScripte verwenden. Bei jeder Ausführung eines solcher Scripte wird seit Jahren eine solche Zeile ins Logfile eines jeden Rechners geschrieben. Auch eine schöne Variante einen Computer zu beschäftigen.

Mich stört so etwas jedenfalls ungemein, hauptsächlich jedoch, weil man stundenlang durch solche unnötigen Meldungen bei der Fehlersuche von eigenen Programmen fehlgeleitet wird. Na klar, auch bei einer solchen Geisterjagd wird man nicht dümmer, aber es hält einen doch sehr davon ab, sein eigentliches Ziel zu verfolgen.


Als ich mal wieder einen meiner USB-Sticks im Windwows-Explorer öffnete, war das Maß endgültig voll. Ich konnte den Anblick von .DS_Store, .Trashes, .Spotlight-V100, .fseventsd, .TemporaryItems nicht mehr ertragen. Diese “Fremdkörper” sind mir von jeher ein Dorn im Auge, zumindest auf Dateisystemen des jeweils anderen Betriebssystems. Das dieses nicht nur ein Spleen meinerseits ist, ergab eine kurze Google-Recherche nach diesen Dateinamen, das Ärgernis darüber ist offensichtlich weit verbreitet und wird schon seit x-Jahren diskutiert.Diverse Entwickler haben sich anscheinend im Laufe der Zeit mit Lösungen für die Beseitigung dieser Angelegenheit auseinander gesetzt. Aber eine All-inclusive-Lösung konnte ich nicht finden, schon gar nicht im OpenSource/Freeware Bereich. Und als passionierter Coder kam eine Kauflösung eines properitären Herstellers nicht in Frage. Also fing ich quick and dirty an, ein kleines bash-Script zu schreiben. Der Aufwand dafür sollte möglichst gering bleiben.

  • Bash – Quellcode des ersten Entwurfs
#!/bin/bash
#set -x
dropList=".DS_Store ._* .Trashes .Spotlight-V100 .fseventsd"
for volume in /Volumes/*; do
 if ! [ -L "$volume" ] && [ -d "$volume" ]; then
  echo touching "$volume/.metadata_never_index"
  touch "$volume/.metadata_never_index"
  for drop in $dropList; do
   if [ -e "$volume/$drop" ]; then
    echo removing "$volume/$drop"...
    sudo /bin/rm -rf "$volume/$drop"
   fi;
  done;
  if ! [ -e  "$volume/.Trashes" ]; then
   sudo /bin/ln -sf "/.Trashes" "$volume/.Trashes"
  fi;
 fi;
done;
echo ""
echo Beliebige Taste um zum beenden.
read
# -eof-

Funktionserklärung

Das Script entfernt die o.g. Dateien/Ordner  aller “echten” Verzeichnisse (keine SymLinks). Leider geht es anscheinend ganz ohne DotFiles nicht. Um Spotlight an der Indexierung zu hindern, ist es erforderlich eine Datei mit dem Namen  “/.metadata_never_index” anzulegen, wenn es denn sein muss, damit sollte man leben können. Als nächstes kommt der /.Trashes Ordner dran. Nicht erst einmal ist es mir passiert, dass ich USB-Sticks weitergegeben habe, auf dem vermeintlich gelöschte Daten im .Trashes befunden haben. Ich will keine Papierkorb Funktion auf FAT/NTFS Dateisystemen. Daher legt das Script einen Symlink/ zu /.Trashes an. Das erfüllt zwar nicht den erhofften Zweck, nämlich den Papierkorb auf dem eigenen Mac zu verwenden, aber es wird auch kein .Trashes Ordner angelegt. Die Dateien werden (nach entsprechender Warnung) sofort entgültig gelöscht.

Dot-Files aufs Minimum reduzieren

Zwei Dot-Files bleiben zurück, bislang fand ich keinen Weg, auch diese zu entfernen.

  • /.Trashes
  • /.metadata_never_index

Aufgrund meines letzten Kenntnisstands sind diese beiden Dateien die letzten, die auf dem Volume zurückbleiben sollten um in Zukunft dem Mac frühzeitig mitzuteilen, sich hier zurückzuhalten.

Nachteile des Scripts

1.) Es werden stets alle gemounteten Verzeichnisse “durchgenudelt”
2.) Man muss das Script manuell starten
3.) Es werden auch Volumes mit HFS Dateisystem bearbeitet, was nicht gewünscht ist.
4.) All dieses würde eine individuelle Konfiguration erfordern.

Alternative Lösung wurde zur App

Es war klar,  “quick and dirty” war nicht ausreichend, aber die Idee war geboren. Als möglicher Weg fielen mir die Ordneraktionen ein, wie sich herausstellte, das Mittel der Wahl. Aber wie geht das? Erst versuchte ich mich mit dem Automator, aber das war zu weit oben. Bei Automator Recherchen wurde auch immer wieder AppleScript genannt, also schaute ich mir das mal an. Kam mir ja erst sonderbar vor, musste mich erstmal komplett neu einlesen. Schliesslich kam ich doch schneller rein als gedacht, ich erkannte viele Parallelen zu Tcl/Tk, welches ich seit mehreren Jahrzehnten einsetze. Auch der AppleScript-Editor ist sehr komfortabel, liefert eine gute Codeunterstützung. Weiterhin gibt es massenhaft Dokumentationen und Beispiele zu AppleScript im Netz. Nach ca. 3-4 Tagen war die “all-inclusive” App fertig für den Einsatz. Ich stelle es gern als Package als Urbanware zur Verfügung. Die genaue Funktionsbeschreibung der App befindet sich hier.


Über GUI, indem man die Verzeichnisdienste aus dem Core-System startet.

% /System/Library/CoreServices/Directory\ Utility.app/Contents/MacOS/Directory\ Utility

Dort erstmal auf das Schloss klickern um Admin-Zugriff zu bekommen, dann kann man im Menü “root User aktivieren” auswählen.

Siehe auch: Ratgeber bei macwelt.de

Viel schneller geht es jedoch, dem root user ein Passwort über das Terminal zu geben.
Falls dieser schon ein Passwort besitzt hat und man möchte es behalten wird es einfach nochmal eingegeben.

% sudo passwd root
Changing password for root.
New password:
Retype new password:
passwd: Unable to change the password for record root.  Credential verification failed because account is disabled

Die obige Meldung, dass das Passwort nicht geändert werden kann ist unwahr, denn der root user ist nun aktiv und das neue (bzw. alte) Passwort ist sehr wohl gültig.