Original-URL des Artikels: https://www.golem.de/news/apfs-in-high-sierra-10-13-im-test-apple-hat-die-macos-dateisystem-werkzeuge-vergessen-1710-130340.html    Veröffentlicht: 12.10.2017 12:15    Kurz-URL: https://glm.io/130340

APFS in High Sierra 10.13 im Test

Apple hat die MacOS-Dateisystem-Werkzeuge vergessen

MacOS mit Apple-PFuSch? Wenn es um das neue Dateisystem APFS geht, hat Apple zwar etwas Robustes abgeliefert, doch das Drumherum stimmt überhaupt nicht, wie ausführliche Tests gezeigt haben. Ansonsten gibt es für Endanwender in MacOS 10.13 alias High Sierra nicht viel zu sehen, was aber gar nicht so schlecht ist.

Wer High Sierra installiert, wird kaum Neues im Alltag entdecken - und das ist durchaus so gewollt. Apple hat es mit der diesjährigen Version 10.13 seines Mac-Betriebssystems nicht auf große Umwälzungen in der Bedienung abgesehen. Vielmehr wurde der Unterbau erneuert, Fehler wurden beseitigt - und Grundlagen für die Zukunft gelegt. Dazu gehört auch ein neues Dateisystem: APFS löst HFS+ ab - jedenfalls fast. Doch hierbei ist nicht alles gutgegangen, auch wenn das Dateisystem selbst stabil ist. Die Aufgabe von HFS+ ist zwar einerseits ein Zwang für bestimmte Anwender. Wer allerdings einen sich drehenden Datenträger hat, der wird nicht umgestellt. Für Mac-Anwender ist das neue Dateisystem eine komplett neue Erfahrung; in der Unix-Welt ist der eine oder andere vielleicht schon mit ZFS oder Btrfs in Berührung gekommen, die ähnliche Funktionen bieten. In unserem Test konzentrieren wir uns daher vor allem auf APFS und den Umgang damit.

Eines vorweg: Am neuen Dateisystem selbst ist uns nichts an Fehlern aufgefallen. Es läuft ohne Störungen und wie zu erwarten. Ein paar Designentscheidungen sind seltsam, aber das war es auch schon. Auffallend ist zudem, dass wir keine Fehler entdeckt haben, die auf Eile hindeuten. Bei unserem iOS-11-Test und WatchOS-4-Test sind uns hingegen auch nach dem Test noch einige unkritische Fehler aufgefallen. Die Softwarequalität von MacOS 10.13 alias High Sierra ist also allgemein gut.

Wichtig zu wissen ist, dass High Sierra die letzte MacOS-Version sein wird, die 32-Bit-Programme noch ausführt. Wie bei iOS 11 wird mit MacOS 10.14 dann die Kompatibilität eingeschränkt.

Bei der Umsetzung von APFS hat es allerdings offenbar Unstimmigkeiten zwischen den Abteilungen gegeben. Mit APFS müssen nämlich einige Programme angepasst werden. Das gilt nicht nur für Drittentwickler, sondern auch für Apple selbst.

Wir haben in kürzester Zeit Eigenarten entdeckt, die nur mit "vergessen" oder "Wir wissen nicht, was wir machen sollen" erklärt werden können. Mitunter muss dem Unternehmen aber auch die Zeit ausgegangen sein. Wir haben uns in Folge das ein oder andere Mal an den Kopf gefasst und dem Linux-Kollegen klappte die Kinnlade herunter. Da die Fehler recht detailliert beschrieben werden müssen, gibt es im folgenden Text ein gewisses Übergewicht gegenüber den positiven Merkmalen, die schnell erklärt sind.

Kleine Änderungen und Nicht-Änderungen

Die Ankündigungsseite von MacOS 10.13 alias High Sierra listet in bunten Bildern nur wenige Änderungen auf. Andere sind gar nicht dokumentiert, fallen dafür aber umso mehr auf. Manche Änderungen wie der neue Safari-Browser sind zudem auch für das alte Sierra-Betriebssystem verfügbar oder - wie die stark überarbeitete Foto-Anwendung - nur eine Bündelung mit dem OS. Tatsächlich lässt sich der große Brocken von High Sierra, APFS, kaum werbewirksam beschreiben.

Manche Änderungen sind auch nicht dokumentiert. So hat Apple ungefragt unsere Signatur-Einstellungen geändert und diese über dem Zitat platziert. Das ist keine gute Idee, wenn Anwender die Signatur korrekt abtrennen, und zeigt, dass Apple leider nicht so recht weiß, wie das mit den E-Mails funktioniert. Denn eine korrekt abgetrennte Signatur wird von guten E-Mail-Programmen nicht zitiert und damit auch nicht das darunterliegende Vollzitat.

Neu bewertet wurden bei uns zudem Spam-E-Mails. Wir wissen nicht genau warum, aber die Erkennung versagte in den ersten Tagen auf zwei Systemen, die beide den gleichen IMAP-Zugang verwenden. Wir würden uns wünschen, dass Apple bei solch gewichtigen Entscheidungen Anwender aktiv informiert. Im Geschäftsbetrieb hat eine plötzliche Neuklassifizierung von E-Mails unangenehme Auswirkungen, insbesondere, wenn man sich einen IMAP-Account teilt oder mit Abonnements arbeitet.

Apple Maps und ÖPNV

Eine wichtige Änderung, die wir auch unter iOS bemerkten, ist, dass die Apple-Karten jetzt den ÖPNV nicht mehr vergessen. Dass Apple Maps seit Sierra Tabs unterstützt, bleibt in der neuen Version aber nutzlos. Tabs werden weiter nach dem Beenden vergessen und es gibt auch kein Caching. Da uns Apple Maps bei der Verwendung von Siri ab und an abgestürzt ist, hatte das kleinere Auswirkungen. Hier hätten wir uns gewünscht, dass Apple den angefangenen Ansatz von Sierra jetzt zu Ende führt.

Die Kartenfunktion ist in Verbindung mit Siri weiterhin mäßig, wenngleich deutlich besser geworden als in Sierra. Während unseres Tests waren wir kurzzeitig auch in Japan. Von der Chiba-Präfektur nach Tokio wurden wir gut geführt, auch die Spracherkennung ist mittlerweile sehr gut. Die Routenplanung nach Shibuya oder Shinjuku stellte ebenfalls kein Problem dar.

Die Wegeführung zum Flughafen hingegen versagt komplett, obwohl sowohl Tokio (deutsche Aussprache), Tokyo (englische Aussprache) als auch Tōkyō (japanische Aussprache) verstanden werden und selbst Narita und Haneda in Kombination korrekt aufgenommen werden. Das Wort "airport" wird auch in der deutschen Version verstanden. Insgesamt eine erstaunliche Leistung. Doch die Zuordnung zu einem Ort versagt, obwohl "Flughafen Tokio Narita" doch sehr eindeutig ist.

Immerhin hat Apple eine Reserve. Ist ein Ort nicht bekannt, gibt es Suchergebnisse, auf die man klicken kann. Bei uns waren sie von Foursquare - leider nur in japanischer Sprache. Das gilt auch für das iPhone. Japan ist übrigens ein Fokus-Land. Nur wenige Länder sind in Apple Maps so gut in der Datendarstellung. Die ÖPNV-Anzeige funktioniert beispielsweise makellos und ist von einer enormen Qualität. Da kommt Google nicht mit.

In Deutschland funktioniert Siri mit Flughäfen

In Deutschland werden Flughäfen gefunden, egal ob wir Tegel oder Schönefeld in Berlin ansteuern wollen - es hat den Anschein, als würden die Länder-Teams für Apple Maps nicht den gleichen Checklisten folgen. Es gibt aber auch hier Einschränkungen: Eine kontextbasierende Suche gibt es mitunter nicht. Die Suche nach dem Flughafen Tegel kann Siri im Deutschen nicht zuordnen, wenn wir uns in Berlin aufhalten. Das System schlägt dann "Flughafen Berlin-Tegel" oder "Berlin-Schönefeld" vor. Sprachlich funktioniert die Suche nur, wenn der Ort mit angegeben wird. Das entspricht nicht unbedingt der natürlichen Sprache und zeigt, dass Siri in der deutschen Sprache noch weit von einem echten Assistenten entfernt ist.

Die menschlichere Stimme von Siri ist unter MacOS noch nicht im Einsatz - dabei ist sie auf dem iPhone schon ziemlich gut und Apple hatte sie für den Zeitpunkt der Veröffentlichung angekündigt. Sie wird also hoffentlich bald nachgereicht.

Auch die Antwortsätze von Siri sind auf dem iPhone mitunter besser formuliert als unter High Sierra. In Stichproben sind die Endergebnisse aber identisch. Es gibt allerdings Unterschiede zwischen Spotlight-Suchen und Siri-Suchen. Nicht alles, was in Spotlight zu einem Ergebnis führt, führt auch in Siri zu einem Ergebnis. Die Suche nach einem Flug und dessen Status geht mit Siri nicht, ist aber eine Neuerung von Spotlight.

Live-Infos zur Position eines Passagierfluges

Spotlight kann jetzt auch Fluginformationen anzeigen. Praktischerweise hat Apple an verschiedene Schreibweisen gedacht. Sowohl "Lufthansa Flug 454" als auch "Flug LH454" funktionieren. Was allerdings nicht funktioniert ist "Lufthansa Flug LH454". Die Funktion der Fluginformationen wurde von Apple erst eine Woche nach der Veröffentlichung von High Sierra freigegeben. Offenbar war das Backend von Spotlight nicht rechtzeitig fertig. Mittlerweile funktioniert dies zuverlässig.

HEVC und HEIF für das Encoding von Videos und Fotos betreffen derzeit nur wenige Nutzer. Die Formate sind deutlich effizienter beim Umgang mit Speicherplatz als die vorheriger Betriebssysteme. Das Anschauen derartiger Dateien stellt unter MacOS kein Problem dar. Programme wie iMovie können zudem seit kurzem HEVC-Videos importieren und verarbeiten. Das ist vor allem wichtig für Nutzer des iPhone 8 und X. Es ist aber zu erwarten, dass ein großer Teil der Mac-Anwender bald regelmäßig auf HEVC zugreifen wird. Apple ist recht radikal, was das neue Format angeht. Wer es komplett einsetzen will, muss High Sierra verwenden. Eine Rückportierung auf alte Betriebssysteme findet voraussichtlich nicht statt.

Noch nicht abschätzbar und testbar sind die Auswirkungen der Grafikschnittstelle Metal 2. Hier müssen die entsprechenden Anwendungen noch in großer Anzahl entstehen. Versprochen werden ein erheblicher Effizienzgewinn und die Unterstützung externer GPUs. Dank Letzterem soll sich auch Virtual Reality beim Mac groß durchsetzen. Es gibt aber eine Änderung, die alle Rechner mit Metal-Unterstützung betrifft. Das Displaylink-Forum hat für High Sierra neue Treiber veröffentlicht, die viele Probleme unter Sierra lösen.

Größere Veränderungen betreffen zudem den Bereich der Sicherheit.

Security

In MacOS High Sierra hat Apple einen Prozess abgeschlossen, der bereits mit der Version OS X Mavericks begonnen wurde. Das Unternehmen versucht, Softwareentwickler von der Verwendung eigener Kernel-Extensions abzuhalten, um die Sicherheit und die Stabilität des Betriebssystems zu verbessern.

Hat ein Programm einen Speicherfehler, betrifft dieser zunächst nur die Applikation selbst. Greift ein Programm aber auf eine selbst entwickelte Kernel-Extension zurück, kann ein Fehler eine Kernel-Panic auslösen oder den Kernel für Angriffe anfällig machen, wenn die Extension fehlerhaft ist. Bereits in MacOS Sierra mussten Kernel-Extensions mit einem speziellen Apple-Zertifikat für Kernel-Extensions signiert sein, um akzeptiert zu werden.

In MacOS High Sierra müssen Kernel-Erweiterungen, die bei oder nach der Installation des Betriebssystems installiert werden, zusätzlich autorisiert werden, Apple nennt diesen Prozess "Secure Kernel Extension Loading" (SKEL). Dafür sind allerdings keine speziellen Administratorrechte erforderlich, jeder Benutzer kann dies also tun. Ausnahmen gibt es für bereits vor einem Upgrade installierte Kernel-Extensions, bereits zuvor genehmigte Erweiterungen und mit derselben ID signierte Erweiterungen wie bereits genehmigte Extensions.

Nutzer können den gesamten Prozess in der MacOS-Wiederherstellung deaktivieren, indem sie dort den Befehl spctl anwenden. In Mobile-Device-Management-Lösungen (MDM) wird SKEL nach Angaben von Apple automatisch deaktiviert.

Kritik an Umsetzung von SKEL

Der Sicherheitsforscher Patrick Wardle von Synack kritisierte jedoch bereits vor der Veröffentlichung, dass dieser Prozess keinen Sicherheitsgewinn bringen würde. Die "Guten" - gemeint sind Softwareentwickler - würden unnötig Hürden aufgestellt bekommen, während "die Bösen" wie Malware-Entwickler davon nicht betroffen sein würden.

Nach Angaben von Wardle kann der Mechanismus in seiner bestehenden Form leicht umgangen werden. Zwar habe Apple offensichtliche Manipulationen wie die Manipulation der "kext policy"-Datenbank ausgeschlossen. Es sei jedoch weiterhin möglich, signierte Kernel-Module ohne Interaktion der Nutzer zu laden. Vollständige technische Details will Wardle erst veröffentlichen, wenn der Bug gepatcht ist, der Bug wurde Apple bereits gemeldet.

Datenschutz und Privatsphäre

Apple will künftig den Einsatz von Cookies durch Drittparteien strenger regulieren. So können Cookies von Anbietern, die nicht direkt mit einer besuchten Webseite zusammenhängen, nach wenigen Tagen blockiert werden und so weniger Informationen über das Surfverhalten sammeln. Auch hier sollen statistische Werte dabei helfen zu ermitteln, ob Nutzer einer Seite erlauben wollen, Cookies von Drittanbietern zuzulassen oder eher nicht.

Mit MacOS High Sierra und iOS 11 weitet Apple außerdem den Einsatz von Differential Privacy aus. Dabei handelt es sich um eine Forschungsrichtung, die es ermöglichen soll, möglichst viel über einzelne Nutzer zu erfahren, ohne personenbezogene Daten zu erheben. Dazu werden den erhobenen Daten Zufallswerte hinzugefügt, die später wieder entfernt werden, wenn eine große Menge an Daten aggregiert wurde. Dies soll es nicht ermöglichen, Rückschlüsse auf einzelne Personen zu ziehen, aber trotzdem relevante Trends zu erkennen.

In einer ersten Version hatte Apple die Technik eingesetzt, um auf Basis von Tastatureingaben bessere Emojis vorzuschlagen. Jetzt soll die Entwicklung für relevantere Einsatzzwecke genutzt werden, etwa für die Systemstabilität.

Differential Privacy in Safari

Der Einsatz von Differential Privacy erfolgt unter anderem im Safari-Browser. Dort sollen anonym Daten über besuchte Webseiten erhoben werden. Wenn bestimmte Webseiten bei besonders vielen Nutzern Probleme bereiten und zu hoher Systemlast oder Abstürzen führen, könnte Safari bestimmte Skripte an der Ausführung hindern und so die Stabilität und auch die Akkulaufzeit eines Rechners erhöhen. Auf jeden Fall können die Informationen bei der Weiterentwicklung des Browsers helfen und dürften genauere Rückschlüsse zulassen als bisherige Crash-Reports.

Ähnliches gilt für die bei vielen Nutzern ungeliebten Autoplay-Videos, wie sie auf vielen Webseiten vorkommen. Anhand der Messung von Nutzerinterkationen soll High Sierra in der Lage sein, künftig zu erkennen, ob Nutzer auf einer Webseite ein Autoplay-Video erwarten oder nicht. Auch hier könnte die Ausführung entsprechender Videos blockiert werden. Videos ohne Ton sollen weiterhin grundsätzlich abgespielt werden.

Zu erwähnen ist, dass mehrere Wissenschaftler im September Apples Verwendung des Begriffs Differential Privacy kritisiert hatten [PDF]. Sie werfen dem Unternehmen vor, die Bedingungen zur Datenerhebung jederzeit ändern zu können, ohne dass Nutzer das mitbekommen würden. Außerdem bewege Apple sich mit seiner Definition des Begriffs am Rande einer streng wissenschaftlichen Definition, da die Anonymisierung nicht so stark sei wie bei anderen Lösungen. Apple hatte die Studie kritisiert und warf den Wissenschaftlern auch methodische Mängel vor.

TLS ohne SHA-1

Mit High Sierra entfernt Apple außerdem die Unterstützung für die seit langem als unsicher geltenden SHA-1-Zertifikate. Entsprechende Zertifikate können also weder im Browser noch für E-Mails oder andere Dienste genutzt werden.

MacOS High Sierra prüft außerdem einmal in der Woche die Firmware auf dem Rechner. Dabei wird die Hardware-ID des Geräts mit einer Datenbank von Firmwareversionen abgeglichen. Stimmen die Versionen nicht überein, bekommen Nutzer eine Warnung.

Eine der größten Änderungen in High Sierra liegt allerdings im Dateisystem.

Einführung in APFS

Normalerweise ist ein Dateisystem für Endanwender nicht interessant. Es erledigt im Hintergrund Aufgaben, die wirklich nur Experten betreffen. Doch unter High Sierra läuft das noch nicht ganz rund. Betroffen ist dabei nicht das Dateisystem selbst, das sich in unserem Test als sehr robust herausstellte: Während des Upgrade-Vorgangs auf mehreren Geräten stürzte uns einer der Macs ab und trotzdem gingen keine Daten verloren. Doch die Infrastruktur um das Dateisystem herum funktioniert nicht so wie erforderlich. Wir fanden aber keine Bugs in APFS, sondern ausschließlich in den Werkzeugen, die das Dateisystem betreffen und auch für Endanwender gedacht sind.

Dass die Implementierung von APFS nicht einfach ist, ist klar. Zahlreiche Dritthersteller haben ihre Probleme mit dem Dateisystem und der rechtzeitigen Anpassung. Apple ist es ebenfalls nicht gelungen, sich an die neuen Gegebenheiten anzupassen - trotz deutlich längerer Vorlaufzeit. Erschwerend kommt hinzu, dass Apple erst vor einigen Monaten mit der Testphase basierend auf der neuen High-Sierra-Plattform anfing. Dass APFS zu dem Zeitpunkt noch nicht fertig war, zeigt der Umstand, dass viele Entwickler APFS noch auf Fusion Drives nutzen, was Apple dann nicht mehr umsetzte und deshalb Entwickler zur Rückabwicklung der Umstellung bewegte. Mutmaßlich wegen Problemen.

Apple geht aber davon aus, dass APFS auf Flash kein Problem darstellt und lässt den Anwendern keine Wahl. Wer eine SSD hat, der muss umstellen. Im Folgenden legen wir allerdings dar, dass auch Apple die Zeit bei der Entwicklung von High Sierra ausging.

Die Möglichkeiten der APFS-Partitionierung

Zunächst wollen wir grob skizzieren, was mit APFS möglich ist, und zwar gänzlich ohne das Terminal und Kommandozeileneingaben. Wir verwenden die Systeminformationen, das Recovery-Werkzeug und das Festplattendienstprogramm (Disk Utility).

Mit diesen Werkzeugen lässt sich der Datenträger dank APFS auf besondere Art und Weise behandeln. Es ist möglich, beliebige Partitionen mit jeweils einem sogenannten APFS-Container aufzubauen. Standardmäßig besteht ein SSD-Mac aus einem APFS-Container. Das Festplattendienstprogramm zeigt an, wie viele Volumes sich diesen teilen. Es sind sogenannte Subvolumes, standardmäßig vier, drei davon sind nicht sichtbar. Das Besondere: Diese APFS-Volumes teilen sich gleichberechtigt den Speicher. Vorbei sind die Zeiten, in denen umpartitioniert werden musste, weil man sich bei der zu erwartenden Größe verschätzt hatte.

Wer will, kann im Dienstprogramm trotzdem Speicher reservieren und eine Obergrenze (Quota) festlegen. Dann hat ein Subvolume eine garantierte Mindestgröße und auch eine maximale Obergrenze. Eine weitere Besonderheit: Der Umgang mit APFS ist äußerst schnell. Volumes lassen sich so schnell erstellen, dass das Eintragen des Namens mehr Zeit kostet. Es ist aber auch ein besonders großer Vorteil von APFS, dass Dateisystemoperationen enorm beschleunigt werden.

Vorteile werden auch direkt nach der Installation sichtbar: Wir haben einen Rechner am Limit betrieben. Mit dem High-Sierra-Installer hatten wir noch 9,4 GByte freien Speicher, etwas mehr als mindestens notwendig ist. Direkt nach der Installation wurden dann durch das automatische Löschen des Installers etwa 5 GByte frei und weitere 5 GByte durch die APFS-Konvertierung und andere Aufräumarbeiten. Diese Aufräumarbeiten belasten das System allerdings für etwa eine Stunde. Derweil schwankte der freie Speicher zwischen 17 und 19 GByte. In dieser Zeit funktioniert das Zusammenzählen von Dateien natürlich nicht so gut.

Zusammenzählen und Duplizieren in Windeseile

Nach dieser Beruhigungsphase haben wir ein paar kleine Messungen durchgeführt. So haben wir etwa die Bibliothek in der Größe vermessen, um zu schauen, ob gerade dort Speicher frei wurde. Die Messungen auf einem Mac Mini vor und nach der High-Sierra-Installation waren aber identisch. Selbiges gilt für ein Macbook 12.

Auffallend ist aber, dass die Berechnung des Speicheraufbaus im "Über diesen Mac"-Dialog unter Festplatte lange dauert - länger als unter Sierra -, ein Phänomen, das uns auch unter iOS bei der Umstellung auf APFS aufgefallen ist und das bisher nicht behoben wurde. Die Anzeige kann durchaus mehrere Minuten dauern. Erst nachdem das gelungen ist, zeigt die Verwaltungs-App übrigens die Größe von Programmen in der Übersicht an. Zwischen 2.000 und 3.500 Lesezugriffe pro Sekunde werden für die Berechnung benötigt, es ist also durchaus eine anspruchsvolle Aufgabe.

Eine weitere Eigenart ist eine Verzögerung der Papierkorbentleerung. Der frei gewordene Speicherplatz wird nicht sofort als solcher im Finder angezeigt. Das hat aber keine negativen Auswirkungen. Wer sich daran stört, der kann mit einem Neustart des Systems eine Aktualisierung erzwingen. Dabei sollte er sich nicht wundern, dass die Speicheranzeige kurz nach dem Booten um etwa 1 GByte schwanken kann, was seltsam anmutet.

Dateien belegen nicht immer Speicherplatz

Selbstverständlich muss das Löschen von Dateien keinen Speicher freigeben. Wenn der Anwender etwa Duplikate löscht, eine Spezialität von APFS, dann passiert nach dem Entleeren nichts. Das Schöne an APFS wird hier zum Nachteil bei der Bedienung. Wer will, kann ohne Verlust von Speicherplatz alles duplizieren, was er will. Nur wenige Hundert Bytes gehen dabei verloren. Bei der Erstellung einer Kopie des Aperture-Bundles zeigt der Finder kurz während des Vorgangs an, dass 434 Bytes erzeugt werden müssen.

Das ist aber auch der einzige Hinweis auf diese APFS-Spezialität. Alles andere ist völlig undurchsichtig. Unsere Aperture-Kopie ist mit 1,29 GByte fast 300 MByte größer, zumindest laut dem Info-Dialog. Zudem verwendet die Kopie auf dem Datenträger 1,15 GByte, das Original nur 585 MByte an Speicher. Jeder, der sich halbwegs mit APFS beschäftigt hat, weiß, dass die Angaben der Apple-Werkzeuge völliger Humbug sind. Für reguläre Anwender kommt es aber zu erheblichen Verständnisschwierigkeiten, sollten sie Dateien duplizieren oder eine Anwendung ein Duplikat anlegen.


Dass das Erkennen eines Duplikats auch auf der Kommandozeile nicht funktioniert, weder mit ls noch stat, stört zusätzlich. Es versteht sich, dass selbst dort falsche Größenangaben angezeigt werden. Vorteilhaft ist aber: Das Duplizieren ist unheimlich schnell und nutzt so gut wie gar keinen Speicher.

Es wird jedes Mal neu gezählt

Ebenfalls schön ist eine weitere Eigenart von APFS: Das Zusammenzählen einzelner Verzeichnisse ist erheblich schneller geworden. Auf unserem Macbook erkannten wir beispielsweise mit High Sierra sofort, dass unser Mail-Ordner 11,5 GByte groß ist. Auffallend ist hier, dass der Info-Dialog aber nicht anzeigt, dass noch eine Berechnung erfolgt. So tauchte die Anzahl der Elemente erst später auf. Als das System dann feststellte, dass rund 320.000 Elemente in dem Mail-Ordner vorhanden waren, wurde die Anzeige auch präzisiert: 12,5 GByte werden genutzt.

Für eine grobe Abschätzung des Ordners ist die Beschleunigung sehr angenehm. Wir würden uns aber wünschen, dass MacOS anzeigt, dass der Wert vorläufig ist. Das fällt allerdings nur bei stark befüllten Ordnern auf. In der Regel werden sowohl die Dateien als auch die genutzte Kapazität so schnell angezeigt, dass das Umspringen der Anzeige nur bei genauem Hinsehen auffällt. Die Geschwindigkeit variiert auch nach Rechner. Unser Mac Mini mit PCIe SSD (Late 2014) ist erheblich schneller bei solchen Operationen als unser Macbook 12 (2015).

APFS haben wir bisher nur intern verwendet, doch auch der Einsatz extern ist möglich.

APFS kann auf externen Datenträgern verwendet werden

Während Apple den Einsatz auf Fusion Drives nicht für die finale Version von High Sierra freigegeben hat, kann der Anwender durchaus APFS auf seinen Datenträgern verwenden. Doch hier ergeben sich die ersten Probleme. Das Festplattendienstprogramm ist darauf nicht so recht vorbereitet.

Auf den ersten Blick dürfte kaum ein Anwender bemerken, dass APFS auch für Festplatten und USB-Sticks verwendet werden kann. Das liegt unter anderem daran, dass Apple die Ansicht vereinfacht und dadurch Prozesse komplizierter und auch unlogischer gemacht hat. In der einfachen Ansicht ist es beispielsweise möglich, einen HFS+-Datenträger in APFS zu wandeln. Datenträger mit MBR lassen sich so aber nicht wandeln. Das liegt daran, dass Anwendern diese Informationen in der einfachen Ansicht vorenthalten werden - ein Problem, das die alte Sierra-Ansicht nicht hatte. Sie ist auch glücklicherweise noch da.

In der einfachen Ansicht wird für einen HFS+-Datenträger unabhängig von GUID oder MBR die Wandlung in APFS angeboten. Bei einem existierenden MBR gibt es aber eine Fehlermeldung von Storage-Kit (Fehler 118). Ähnlich verhält sich das Löschen oder auch Neuformatieren. Bei einem MBR-Datenträger wird APFS gar nicht erst angeboten. Warum das so ist, erfahren Anwender jedoch nicht. Bei einem GUID-Datenträger hingegen gibt es APFS in der Dropdown-Liste für Dateisysteme. Konsequenter wäre es gewesen, in der einfachen Ansicht APFS grundsätzlich nicht anzubieten. Gemessen an der Nutzerfreundlichkeit ist diese Vereinfachung von Apple äußerst schlecht.

In der erweiterten Ansicht geht natürlich alles, denn dort ist klar, was wann wie passieren muss. Zudem löst die erweiterte Ansicht ein Designproblem, das Apple seit der Freigabe des exFAT-Dateisystems im Jahr 2010 nicht angepackt hatte: Mitunter formatiert man sich seine Datenträger temporär kaputt. In der einfachen Ansicht haben wir mehrfach eine USB-Festplatte mit 2 TByte nicht formatieren können. Einmal hatten wir am Ende nur noch 256 MByte Speicher. Für bestimmte Formatierungen ist es aber zwingend notwendig, weiter oben im (versteckten) Baum zu löschen. Die einfache Ansicht verhindert dies effektiv.

Mit viel Erfahrung funktioniert auch die vereinfachte Ansicht

Die einfache Ansicht lässt aber durchaus Schlüsse auf die Struktur zu. Wer etwa in der Beschreibung eine APFS-Disk1s1 neben einer Disk1s5 sieht, der weiß, dass diese einem gemeinsamen Container angehören. Die angeblich komplizierte erweiterte Ansicht stellt das aber einfacher dar und ist einfacher zu bedienen.

Uns ist nicht klar, ob Apple mit diesem Weg Anwender davon abbringen will, APFS zu nutzen oder doch eine Nutzung unterstützen will. Auf der einen Seite sind die Werkzeuge sichtbar, auf der anderen Seite funktionieren sie jedoch nur in bestimmten Abfolgen bei bestimmten Ansichten ohne Fehlermeldung. Immerhin: APFS funktioniert auf externen Datenträgern und die Konvertierung von HFS+ ist ohne Datenverlust blitzschnell möglich, sofern GUID als Basis vorlegt. Apples Partitionstabelle verhält sich wie MBR und zeigt die gleichen Fehlermeldungen.

APFS lässt sich ohne Probleme auch an Sierra-Macs verwenden. Wir haben das mit einem MacOS 10.12.6 verifiziert. Wer ein durchgepatchtes MacOS 10.12 alias Sierra nutzt, der kann APFS-Datenträger sowohl auslesen als auch beschreiben. Einschränkungen gibt es nur im Festplattendienstprogramm. Dort lässt sich der Datenträger nicht nochmals in APFS löschen. Das war unserer Meinung nach aber zu erwarten. Tatsächlich hat Apple jedoch APFS in Sierra aus unbekannten Gründen eingeschränkt.

Wenig hilfreich ist bei allem die Hilfe. Die behauptet nämlich grundsätzlich, dass Volumes sich auch in HFS, FAT oder exFAT formatieren lassen und zeigt dazu das Beispiel eines APFS-Subvolumes innerhalb eines APFS-Containers. Das lässt sich logischerweise nicht in andere Dateisysteme umformatieren. Wer auch immer die Hilfe angepasst hat, dem fehlt das Wissen um das Dateisystem.

Aber nicht nur die Hilfe wurde nicht angepasst, wir haben sogar ein Apple-Programm gefunden, das mit APFS nicht korrekt arbeitet.

Tests auf Basis des Builds 17A365

Der Vorwurf an Dritthersteller, die sich nicht rechtzeitig an das jeweils neue MacOS angepasst haben, lautet gerne: Es war genug Zeit da, Apple trägt keine Schuld. Umso erstaunter waren wir dann allerdings, als wir Screenshots mit dem Golden Master Candidate (Build 17A362a) kopieren wollten. Das ging nämlich nicht, mit der Anwendung Digitale Bilder (Image Capture.app) per Drag-and-Drop Bilder auf ein APFS-Testvolume zu kopieren. Angeblich fehlten uns Schreibrechte für das Volume.

Wir dachten erst, das wäre ein Problem des Golden Master. Da wir den Bug als potenziellen Blocker einstuften und diverse andere Eigenarten, vor allem mit den Containern, entschieden wir uns, auf das Build 17A365 zu warten, das für alle als final freigegeben wurde. Doch auch mit der Release-Version klappte es nicht und das eilig als Supplemental nachgeschobene Build 405 versagte ebenfalls.

Nun hantieren wir nicht das erste Mal mit Dateisystemen. Derartige Probleme, egal auf welchem Betriebssystem sie entstehen, haben eigentlich immer eine einfache Lösung: Man erstelle einen Unterordner. Wir versuchten das also auch mit dem nackten APFS-Volume. Und siehe da: Image Capture konnte per Drag-and-Drop die Bilder kopieren. Anschließend bewegten und kopierten wir jeweils einmal per Drag-and-Drop im Finder ins Wurzelverzeichnis des Volumes. Das funktionierte wie zu erwarten. Das Problem betrifft nicht nur Drag-and-Drop, sondern auch den Import-Dialog mit Zielauswahl. Digitale Bilder geht offenbar anders mit Dateisystemen um und Apple konnte die Anwendung nicht auf APFS vorbereiten.

Nur ältere Programme sind anscheinend betroffen

Es sind aber nicht alle Programme betroffen. Wer einen Anhang aus Mail.app herauszieht und in ein APFS-Volume ablegt, hat keine Probleme. Wir vermuten, dass vor allem Programme mit älterem Design betroffen sein könnten. Erste Hinweise gibt es darauf bereits bei diversen Profiprogrammen. Und auch traditionell recht systemnah arbeitende Spieleentwickler beklagen massive Probleme. Dass es ausgerechnet Apple erwischt, verwundert allerdings nicht. Die Anpassung an neue Dateisysteme ist ein hochkomplexer Prozess, weswegen eine Zwangsumstellung aller Anwender keine gute Idee ist.

Und damit hört es nicht auf. Denn Apple hat auch zwei andere Programme nicht an die Eigenarten von APFS angepasst: den "Über diesen Mac"-Dialog und das Festplattendienstprogramm. Um das zu erklären, müssen wir allerdings zunächst einmal auf das Container-Konzept von APFS zurückkommen.

Facepalm-Momente mit APFS

Schon nach wenigen Stunden des Testens war uns klar: Apple versagt mit seinen Werkzeugen, wenn es um APFS-Datenträger geht. Die Beispiele dafür sind erstaunlich zahlreich und mit systematischem Tests können sie nach unserer Einschätzung nicht übersehen werden. Insbesondere da unsere Tests keinem explizit konzipierten Testszenario mit dem Ziel des Findens von Fehlern folgen. Wir haben eigentlich nur ein wenig ausführlicher die Neuigkeiten von APFS ergründet und bei jedem Problem versucht herauszufinden, warum es aufgetreten ist.

Wer sich schnell einen Überblick über seine Speicherkapazität verschaffen will, der macht das über den Dialog "Über diesen Mac". Doch nach ein paar Experimenten mit APFS, Containern und Subvolumes hatte unser Mac plötzlich erheblich mehr Speicherplatz, als er haben sollte. Wir verifizierten das noch ein paar Mal und nutzten für die Partitionierungstests sowohl das Macbook Air 2013 als auch eine externe USB-SSD. Der "Über diesen Mac"-Dialog zeigt dann konsequent falsche Werte an.

Unsere 240-GByte-SSD nutzte laut der Anzeige 100 Prozent des Speichers für die beiden HFS- und exFAT-Partitionen. Doch auf der SSD haben wir noch zwei APFS-Container mit Volumes untergebracht. Diese haben jeweils als einzelne physische Disks 40 GByte. Unsere externe SSD ist also wundersamerweise auf 320 GByte angewachsen. Die Darstellung im Festplattendienstprogramm ist da besser, allerdings nur in der erweiterten Ansicht. In der einfachen Ansicht bleiben Anwender auf der Strecke; gerade wenn sie viele USB-Medien verwenden, gibt es keinen Durchblick mehr.

Die Ansicht im Terminal (diskutil list) ist da aufschlussreicher und eindeutiger, auch wenn sie Vorwissen verlangt. Noch mehr Vorwissen ist aber nötig, um die Falschdarstellungen in den grafischen Werkzeugen zu interpretieren. Das ohnehin komplexe Container-Thema wird dadurch noch schwieriger. Ein Test mit einem weniger versierten Anwender ergab, dass die Person davon ausging, dass der Rechner mehr Speicher hatte, als tatsächlich vorhanden war. Augen auf beim Gebrauchtkauf!

Boot Camp akzeptiert angeblich nur HFS+

Schwierigkeiten mit Containern hat offenbar auch Boot Camp. Der Assistent zum Installieren von Windows stürzte auf unserem Macbook Air sofort ab. Es liegt sehr nahe, dass dies mit der Partitionierung zu tun hat. Und siehe da: Nachdem wir alle unnötigen Container, Partitionen und Volumes gelöscht hatten, zeigte sich, dass der Boot-Camp-Assistent wieder korrekt arbeitete.

Wir konnten das Problem allerdings nicht reproduzieren. Mit mehr Partitionen startete der Assistent danach wieder. Wir entdeckten aber ein neues Problem: Bei fünf Partitionen gibt es eine Fehlermeldung. Boot Camp beschwert sich, dass keine Partition angelegt werden kann. Ferner muss das Startvolume als "Mac OS-Extended (Journaled)", also HFS+, vorliegen, sonst erlaubt Boot Camp keine weiteren Aktionen. Diese Fehlermeldung stimmt natürlich nicht. Der Anwender hat bei SSDs keine Wahl und muss APFS einsetzen. Da die Fehlermeldung einfach zu beheben ist und im Endeffekt keine Auswirkungen hat, interessierte uns das nicht weiter. Es erstaunt aber doch, dass solche Fehler auftauchen. Der Apple-Support darf dies dann ausbaden.

Doch damit nicht genug, auch das Festplattendienstprogramm zeigte Auffälligkeiten, die wir allerdings nicht vollständig reproduzieren konnten. Getestet wurde das Folgende auf dem Mac Mini (System 1, Build 17A362a), einem Macbook 2015 (System 2, Build 17A365) und einem Macbook Air 2013 (System 3, Build 17A365). Das reichte erstaunlicherweise aus, um auf allen Maschinen Probleme sehen zu können. Mit Maschine 1 und 2 waren beide nicht in der Lage, APFS-Partionierungen durchzuführen. In so einem Fall empfiehlt Apple eine Reparatur. Die Fehlermeldungen sind allerdings sehr seltsam.

Überprüfung geht nur mit dem Boot-Volume in einem Container

So lässt sich der Container, der die Subvolumes enthält, etwa nicht prüfen. Grund: Der Container enthält ein gebootetes Volume. Interessanterweise ist es aber möglich, ein gebootetes Volume dieses Containers zu prüfen, dafür wird es temporär eingefroren. Auf System 1 erhielten wir den Fehler: Snapshot Tree Invalid. Ein parallel liegendes Volume lässt sich wiederum nicht prüfen. Grund: Das Volume ist eingebunden. Anwender müssen dieses irrelevante Volume per Hand ausklinken, also deaktivieren.

Beim Versuch, nach einem Unmount das Volume zu prüfen, gibt es wieder eine Fehlermeldung: Parallel liegende Volumes, also auch das prüfbare Boot-Volume, verhindern eine Prüfung und müssten auch ausgeklinkt werden. Spätestens da schlägt sich der versierte Anwender mit der Handfläche gegen die Stirn. Immerhin ließ sich das Device dort prüfen, wo die Partitionstabelle liegt, und es gab keine Probleme. Die Lösung ist einfach: Während das Boot-Volume jederzeit in einem Betriebssystem geprüft werden kann, muss ein parallel liegendes Volume im selben Container mit einem Not-System geprüft werden. Wir haben das mit dem High-Sierra-Installer verifiziert. Aber auch da muss das Boot-Volume deaktiviert werden, damit ein paralleles Volume geprüft werden kann. Zudem kann der Installer vom USB-Stick bestimmte Bereiche nicht überprüfen. Das Dienstprogramm dort verweist auf das Recovery-System, von dem man booten soll.

Einen Schreckmoment hatten wir bei ausgeklinkten APFS-Volumes innerhalb eines Containers. In diesem Falle funktioniert die Berechnung der Größe für die Partitionierung nicht mehr. Zum Glück hat das keine Auswirkungen. Ist ein Volume ausgeklinkt, wird im grafischen Partitionierungswerkzeug der gesamte Speicherbereich des Containers als verfügbar für eine weitere Partition angezeigt. Der Schieberegler lässt sich also auch in den vollen Bereich bewegen.

Bei dem Versuch, einen derart destruktiven Vorgang durchzuführen, gibt es dann die Fehlermeldung, dass der Speicherplatz nicht ausreiche. Es zeigt sich wieder: Das Dateisystem ist robust und anscheinend auch die Grundfunktionen für den Umgang. Doch bei den Werkzeugen hat Apple Basisfunktionen schlicht vergessen oder falsch implementiert. Es deutet sich an, dass die Entwickler der grafischen Werkzeuge nicht wissen, wie APFS im Kern funktioniert.

Weil einiges nicht so recht funktionierte, probierten wir weiter mit den nächsten beiden Systemen.

Auf dem zweiten System, dem Macbook 12, lag das Problem woanders. Hier gab es ein Problem beim Verändern der Container-Struktur. Als Warnung wurde eine Overallocation entdeckt. Hier gibt es bei der Art des Scannens die gleichen Einschränkungen wie beim System 1. Es liegt also nicht an der Build-Nummer. Unser Macbook hat allerdings eine Fehlermeldung auf Geräteebene generiert: Probleme wurden in der Partitionstabelle gefunden, die ein Booten verhindern könnten, aber nicht müssen. Glücklicherweise funktioniert unser System allerdings wie gewohnt. Wir glauben eher an einen Anzeigefehler wie bei Boot Camp. Hier werden Fehlermeldungen einfach falsch interpretiert, tatsächliche Fehler liegen nicht vor, zumal eine weitere Überprüfung auch keine Ergebnisse brachte.

Wir wollten aber sichergehen und starteten dafür den Mac im Recovery-Modus. Der Erste-Hilfe-Dialog findet die Fehler dort natürlich auch, kann das Problem aber nicht beheben. Wir werden auch im Recovery-Modus aufgefordert, die Erste-Hilfe-Funktion im Recovery-Modus zu verwenden. Die Partitionierung funktionierte zudem ebenfalls nicht im Recovery-Modus.

System 3 gehörte dann zu denen, bei denen mit APFS-Partitionierungen alles klappt, was uns die Möglichkeit gab, neue Fehler in den Werkzeugen zu entdecken.

Auch das dritte System macht Schwierigkeiten

System 3, das Macbook Air, stürzte während des Upgrade-Vorgangs ab. Neben externen Disks war das unsere APFS-Spielwiese. Die anderen beiden Systeme waren hingegen Produktivsysteme. Da das Internet-Recovery nicht funktionierte - unser WLAN-Passwort wurde nicht akzeptiert -, erstellten wir eine Installationsdisk.

Mit High Sierra ist das erfreulicherweise einfacher geworden, für Endanwender allerdings immer noch eine Herausforderung. Für so einen Fall braucht es einen zweiten Mac und Apple verlangt die Nutzung des Terminals. Dort muss aber nur ein Sudo-Befehl gegeben werden, der Prozess dauert nur ein paar Minuten. Englischkenntnisse werden derzeit auch gefordert. Der Deutsche Service-Artikel wurde bis zum 3. Oktober 2017 noch nicht aktualisiert. Die Rettung verlief ohne Probleme und es gingen auch keine Daten verloren. APFS ist in diesem Fall robust gewesen.

Zwei APFS-Container müssen hintereinander angelegt werden

Hier kommen dann allerdings die nächsten Design- und Logikfehler zum Tragen, die uns auf System 1 und 2 verborgen blieben. Apple erlaubt etwa die Erstellung mehrerer APFS-Container-Partitionen in einem Rutsch. Doch nach dem Anklicken von "Anwenden" wird nur eine Partition angelegt und es folgt eine Fehlermeldung. Das konnten wir auf der externen SSD reproduzieren. Der Grund ist demnach "ein interner Statusfehler". Wenn wir per Hand hintereinander zwei APFS-Container erstellen, gibt es keine Probleme. Mischt man einen APFS-Container mit einer anderen Partition (etwa exFAT oder HFS+), macht das überhaupt keine Probleme. Das Anlegen mehrerer Partitionen versagt nur bei APFS. Das gleichzeitige Löschen mehrerer APFS-Container stellt wiederum kein Problem dar.

Das Anlegen von Volumes ist dank APFS übrigens erheblich leichter geworden. Subvolumes lassen sich binnen Sekunden anlegen. Selbiges gilt für das Aufteilen von Containern. Anwender müssen nur die Unterschiede zwischen Container und Volumes verstehen. In der einfachen Ansicht ist das unserer Meinung nach aber nicht möglich. In der erweiterten Ansicht erschließt sich die Logik hingegen sofort.

Da wir nicht davon ausgehen, dass Apple die Ansichts- und Formatierungsprobleme je lösen wird, schließlich hätte Apple das schon 2010 erledigen müssen, empfehlen wir, immer auf die erweiterte Ansicht umzuschalten und weiter oben im Baum Datenträger zu formatieren. Lästig ist allerdings, dass selbst im Recovery-Modus die Umschaltung erfolgen muss. In einer Umgebung, die eher erfahrene Anwender nutzen, ergibt es keinen Sinn, die Ansicht zu vereinfachen. Wenn das gemacht wird, dann passieren auch keine Fehler. Uns wundert nur, dass Apple mit der Vereinfachung der Ansicht Nutzerfrust provoziert. Wer sich mit Dateisystemen auskennt, der weiß damit umzugehen. Wer aber einfach nur seinen Datenträger löschen will, der kommt damit nicht unbedingt zurecht.

Für all diese Fehler und Designpatzer mit den APFS-basierten Tools gibt es nur zwei mögliche Erklärungen. Entweder hat Apple nicht systematisch getestet, was wir für unwahrscheinlich halten. Oder Apple hat bewusst zwecks pünktlichem Release die Bugs und Designschwächen durchgelassen. Neu wäre das Verhalten nicht. Apple hat seit ein paar Jahren die Priorität auf scheinbare Neuerungen gelegt und dafür die Softwarequalität geopfert.

Wir finden Apples Verhalten sehr bedenklich, schließlich geht es hier um Dateisysteme und nicht eine Foto-App. Da muss alles stimmen. Das Dateisystem selbst zeigte zum Glück keine Fehler. Aber aufgrund der noch nicht fertigen Werkzeuge halten wir eine Zwangsumstellung für den falschen Weg und uns wundert nicht, dass auch andere Entwickler Schwierigkeiten mit APFS haben. Legt man Erfahrungen von ZFS und Btrfs zugrunde, wird Apple auch noch mehrere Jahre brauchen, bis alles rund um APFS stimmt. Der Aufwand ist wirklich sehr hoch.

Externe APFS-Backups gibt es nicht

Noch liegt einiges ohnehin brach. Apple verspricht zwar, dass MacOS High Sierra dank APFS ein einfacheres Backup unterwegs ermöglicht. Doch APFS wird für Backup-Medien nicht unterstützt. Mal eben schnell ein Notbackup ist mit Time Machine jedenfalls nicht zu machen. APFS ist mit seinen Snapshots aber für die lokalen Backups auf demselben Datenträger von Relevanz. Davon sieht der Anwender aber nichts.

Reagiert hat Apple mittlerweile mit einem hastig nachgeschobenen, immerhin rund 900 MByte fassenden, außerplanmäßigen Patch. Das sogenannte Supplemental beseitigt laut Apple diverse Probleme, allerdings keine der von uns entdeckten. Wichtig ist der Patch dennoch, denn eine eklatante Lücke in der Verschlüsselung wurde beseitigt, die eigentlich auch mit systematischem Testen hätte entdeckt werden müssen. Apple hat nicht gerade wenig Arbeit in den Patch gesteckt, das deutet zumindest die neue Build-Nummer 17A405 an.

Allgemein lässt sich sagen, dass der Umstieg auf APFS nicht nur unvollständig ist, sondern auch verfrüht. Die Meldungen zu Problemen mit dem Dateisystem haben zugenommen. Je systemnaher eine Anwendung arbeitet, desto höher die Wahrscheinlichkeit, dass es Probleme gibt. Das betrifft aber nur einen kleinen Teil der Anwender und diejenigen, die hoffen, sich mit APFS Aufgaben vereinfachen zu können. Systemnahe Spiele, die Entwicklungsumgebungen für Spiele oder einige Adobe-Anwendungen betreffen nicht das Gros der Nutzer. Es zeigt aber, dass Apple Probleme mit der Zielgruppe in Kauf nimmt.

Verfügbarkeit und Fazit

High Sierra alias MacOS 10.13 steht als kostenloses Update über den App Store bereits zur Verfügung. Der Download belegt etwa 5 GByte auf dem Datenträger. Zur Installation sind weitere 9 GByte freier Speicher notwendig. Weitere Update-Voraussetzungen sind im Detail bei Apple gelistet. In der Regel wird die 2010er-, in einigen Fällen auch die 2009er-Generation noch unterstützt.

Fazit

High Sierra ist ein gutes Betriebssystem, an dem es an sich nichts zu meckern gibt. Schließlich gibt es kaum Änderungen bei der Bedienung und es ist davon auszugehen, dass eine große Zahl Fehler behoben wurde. Wir haben jedenfalls auf der Oberfläche keine neuen Eigenarten entdeckt. Auch das neue Dateisystem hat Vorteile, sei es das schnelle Zusammenrechnen von Dateien, die extrem schnelle Umpartitionierung oder das sinnvolle Teilen von Speicherplatz zwischen Volumes.

Probleme mit APFS direkt hatten wir keine, sieht man von dem peinlichem Drag-and-Drop-Problem mit der Funktion Digitale Bilder ab. Ein paar Änderungen bei der Foto-Anwendung oder die Anzeige der Fluginformationen sind auch recht praktisch. Schade ist allerdings, dass Apple einige Sierra-Neuerungen nicht konsequent verbessert hat, wie etwa die Tabs in Apple Maps, die weiterhin dem Anwender keine Vorteile bringen.

Die Pfuscherei, die sich Apple rund um die APFS-Werkzeuge erlaubt, stimmt uns allerdings bedenklich. Einerseits erwartet Apple von seiner Entwickler-Kundschaft, sich binnen anderthalb Jahren komplett an APFS anzupassen und fordert die Entwicklergemeinschaft allgemein im Jahresrhythmus stark.

Auf der anderen Seite ist Apple aber selbst mit erheblich längerem internem Vorlauf nicht in der Lage, sein Mac-Betriebssystem an das neue Dateisystem anzupassen. Der Vorlauf für die Drittentwickler ist dabei sehr kurz, denn erst mit dem Build 17A362a gab es eine finale Plattform, die für Entwickler eine Garantie darstellt, dass sich nichts mehr ändert. Dass sich etwas änderte, bewies Apple mit seinem APFS-Experiment für Festplatten, das kurzerhand in der Entwicklungsphase rückgängig gemacht werden musste.

Die Zwangsumstellung für Anwender hätte definitiv nicht sein müssen, denn auch Apple braucht unserer Einschätzung nach noch mindestens ein Jahr, um die gröbsten Ungereimtheiten zu beseitigen. Zudem bringt die Massenverteilung auch Apple erst einmal nichts, denn für Fusion Drives gilt sie nicht. Apple sollte wieder vorsichtiger mit seinen Betriebssystemen werden und vielleicht mal eine Pause einlegen, anstatt starr jedes Jahr Neuerungen zu erzwingen.  (ase)


Verwandte Artikel:
MacOS 10.12 im Test: Sierra - Schreck mit System   
(20.09.2016, https://glm.io/123242 )
Retrofit Kit: Alte MacOS-Versionen für APFS fit machen   
(22.02.2018, https://glm.io/132913 )
Carbon Copy Cloner: APFS-Unterstützung wird wegen Datenverlustgefahr beschränkt   
(17.02.2018, https://glm.io/132831 )
Apples neues Dateisystem: Paragon bringt Windows ein bisschen APFS bei   
(20.12.2017, https://glm.io/131768 )
iOS 11.1 & MacOS High Sierra: Apples Krack-Patches sind nicht mehr Beta   
(01.11.2017, https://glm.io/130906 )

© 1997–2020 Golem.de, https://www.golem.de/