https://www.heise.de/mac-and-i/meldung/Apple-Dateiformat-APF S-Datenverlustgefahr-bei-Images-3972039.html?wt_mc=rss.ho.be itrag.atom

Heise..? Eben...

Nein, - Nicht Heise, Bombich!
Aber: Von dem Problem betroffen sind zudem nur Nutzer, die APFS-Disk-Images auf Medien haben, die schon stark gefüllt sind – ist genügend Platz vorhanden, dürfte sich der Bug zunächst nicht äußern.

Was machst du?
Vielleicht postest du Links so, dass man auch drauf klicken kann

Ich kann das garnicht öffnen...

ich öffne es nich, aber ich denke mal das "Leerzeichen" bei APF S muss weg..?

Danke für die Warnung.

Danke, dass du ordentlich verlinkt hast.

Könnten wir uns drauf einigen, im ersten Posting vielleicht nicht nur einen Link hinzurotzen, sondern auch einen sinnvollen Titel zu vergeben und in ein paar dürren Worten zusammenzufassen, worum es geht? Danke.

Superidee! Und nicht mal neu. +1 👍
Aber manche TEs überforderst du damit gnadenlos....

Hallo,

ok, ich weiß nun nicht, warum der Link nicht geht. Ich kann nicht mehr tun als diesen per drag und drop einzufügen!

Es geht um das Dateiformat APFS und den Verlust von Daten und was Bombich dazu sagt.

https://www.heise.de/mac-and-i/news/

Steht ganz oben!

eigentlich müsste der Link gegehn:

https://www.heise.de/mac-and-i/meldung/Apple-Dateiformat-APF S-Datenverlustgefahr-bei-Images-3972039.html

Das Leerzeichen zwischen APF und S killt deinen Link.
Du könntest dir ruhig etwas mehr Mühe geben. Hat noch niemandem geschadet.

Du könntest dir den Link anschauen, hinterher, wie er im Forum erscheint.
Ich tippe mal, daß er im Original irgendwie in einer schmalen Spalte erschien und deshalb umgebrochen wurde (also in mehreren Zeilen).
Kann sein, daß dann bei D&D anstelle der Zeilenumbrüche Leerzeichen eingefügt werden.
Sind ja zwei, nicht nur "APF S", später noch "be itrag.atom".
Theoretisch könnte die Forensoftware das sicher korrigieren - dafür müsste sie aber irgendwie wissen, daß das eine URL ist… Auch bei https am Anfang nicht immer ganz einfach.

Also die Leerzeichen werden automatisch eingefügt... Das ist hier und auf vielen anderen Seiten so...

Aber Foti du kannst hier auf MTN auch einen Link posten der dann durch ein Symbol aufrufbar ist... Einfach auf das @ Symbol klicken und den Link dann einfügen...

Ob das mit der Iphone App geht, weiß ich nicht...habe ich noch nie probiert...

Das liegt aber an mtn das die links kaputt gehen, also Ruhe bewahren.

viele andere Seiten haben aber eine automatische Linkerkennung

Und ja, die App kann es.

Ist das Thema nicht interessant genug, dass man sich hier nur noch um die Form des Eröffnungspost streitet (inclusive. meines Beitrags natürlich)?

Das sollte dem Thread-Ersteller hoffentlich zu denken geben.

Leider muß man neuerdings immer öfter sagen: Epic fail, apple!

OK!

Ok? Was bedeutet jetzt OK?
Ich finde das Thema interessant.
"Epic fail" find ich übertrieben, aber es häuft sich tatsächlich in letzter Zeit... bedauerlich
Da fast nur noch PCI HDs verbaut sind, diese in Books auch kaum mehr zu wechseln sind, stößt man unter umständen sehr schnell ans Ende der Kapazitäten der Festplatte. Ich z. B. muss regelmäßig auslagern. Filme, Fotos... und die Cloud ist nicht immer praktisch. Bilder geraten immer wieder in Unordnung, Filme lassen sich nicht überall - schlechtes Netzt in z. B. Hotels - nachladen.

Ich schleppe trotz iCloud immer eine kleine SSD mit... Der Preis für den Schlankheits- und Klebewahn.
Da fehlt es mir noch, dass jetzt Daten zerstört werden könnten, wenn die interne HD zu voll wird...

Wie sieht es da eigentlich beim iPad Pro aus... stehe kurz vorm Kauf und bin mit dem Preis am hadern... 64 oder 256 GB...?
Ist iOS mittlerweile auch im APFS Dateiformat?

Ja ist es und ich hadere auch, nehme aber 256, das Gerät bleibt länger in meinem Besitz und ersetzt tatsächlich mehr und mehr mein mbp.

Du hast aber schon gelesen, worum es bei dem Problem eigentlich geht?

Kernaussage des links
äh. ja. Und?

das Phänomen ist eigentlich schon bald 30 Jahren bekannt:
Wenn Festplatte(Image) voll, dann Probleme.

Nehmt mal eine Virtuelle Maschine (egal ob VMWare, Parallels, oder VirtualBox) auf einer ziemlichen vollen Festplatte und speichert unter einem Gast-System mehrere große Dateien.
Viel Spaß

iOS verwendet, dachte ich schon länger, AFPS. Was aber vollständig undramatisch ist:
- Speicher sollte durch ganz viel Speicher ersetzt werden
- generell: immer 20% (Platten-)Speicher freihalten

Ich hab 256gb gewählt... Je nach dem, was man macht, wie viele Apps man nutzt...
geht der Speicher schnell aus... Vorallem bei viel Musik, Videos usw...

Doch. Kannst Du. Die Kommentarfunktion im Forum hat eine Funktion dafür, Links einzubinden (4. Button von links im Kommentareditor, '@'). Damit funktionieren die Links dann auch, weil sie nicht umbrochen werden.

Um das eigentliche Problem mal zusammenzufassen und auf eine dem Grad der Problematik angemessene Größe einzudampfen:

Das Problem tritt auf, wenn man

a) APFS-Dateiimages nutzt und
b) diese Dateiimages automatisch wachsen (sparse disk image) und
c) die Platte, auf der das Image liegt, nicht mehr genügend Platz für die Erweiterung hat, wenn es wächst.

Das ist immer noch ziemlicher Mist, aber ein eher selten auftretender Fall. Die Vereinfachung "APFS verursacht Datenverlust" ist auf alle Fälle überdramatisiert und m.E. eine unzulässige Vereinfachung.

Verstanden habe ich, dass das MacOS (iOS?) den belegten Festplattenplatz einer APFS formatierten Platte in nicht richtig ermittelt, so dass es passieren kann, das bei Grenzwertig vollen Platten Daten überschrieben werden könnten, da irrtümlich Platz ausgewiesen wird.
Und das ist falsch? Klär mich auf - vielleicht hab ich es wirklich falsch verstanden.
Danke

OK - niemand möchte dramatisieren, ich zumindest nicht.
Aber auch in deiner Erklärung verstehe ich doch, das bei einer kleineren Platte das Problem recht schnell auftreten kann - was sind heute schon 64 GB bei einem iPad Pro 7 was sind 256 GB auf einem MacBook Pro...?

Was ich nicht verstehe ist deine Antwort b:
"diese Dateiimages automatisch wachsen (sparse disk image) und"

Du hast beim Anlegen von Disk Images die Wahl, ob sie gleich die volle Größe haben sollen oder nur so viel Platz belegen, wie gerade Daten darauf abgelegt sind.

Im zweiten Fall wächst das Image dann halt, wenn man mehr darauf kopiert, bis es die maximale Größe erreicht hat. Und dabei tritt der Fehler auf: Wenn das Image auf der Platte nicht mehr wachsen kann, meldet APFS den Schreibvorgang auf das Image trotzdem als erfolgreich zurück. Die Daten sind aber natürlich nicht wirklich da (wie auch, sie passen ja nicht auf die darunterliegende Platte). Dann tritt der Fehler auf.

Generell bei allen Systemen gilt, daß man Platten nach Möglichkeit nicht so voll schreiben sollte, daß es eng wird, und das gilt verstärkt für Platten, auf denen das Betriebssystem liegt. Die Performance leidet darunter erheblich.

Wenn also Deine Platte schon so voll ist, daß ein darauf befindliches sparse image in dieses Problem läuft, dann hast Du auch schon an anderer Stelle eines. Etwas anderes ist das bei reinen Datenplatten, aber auch die sollten im laufenden Betrieb eigentlich nicht in so kritische Füllstände laufen, wenn sie regelmäßig beschrieben werden.

In der professionellen IT gibt es zur Vermeidung solcher Probleme Monitoring ... davon lebe ich seit ein paar Jahrzehnten

Für alle Fälle nochmal als Antwort auf Deine Frage:

Es passiert nicht, wenn Deine APFS-formatierte Platte grenzwertig voll ist.

Es passiert, wenn Du ein APFS-formatiertes sparse image auf einer grenzwertig vollen Platte hast, und Du schreibst Daten in das sparse image, die nicht mehr auf die grenzwertig volle Platte passen, auf der es liegt. Die Daten, die Du auf das sparse image geschrieben hast, sind dann weg.

Peter Eckel hat den auftretenden Fehler sehr gut präzisiert.

Wenn wir davon ausgehen, dass die meisten Leute den freien (Festplatten-)Speicherplatz ihrer Geräte im täglichen Gebrauch im Auge behalten, so ist das eigentliche Problem der Einsatz bei Datensicherungs-Systemen.
Da weiß man schlicht weg vorher nicht, wieviele Daten bei der nächsten Datensicherung anfallen.

Wird eine Datensicherung z.B. per Script durchgeführt und es fallen viele Daten an, so kann sich bei der Datensicherung die Woche über das obige Problem sehr unschön bemerkbar machen: die letzte Datensicherung ist dann u.Ust. defekt / nicht verwendbar.
Es ist dann aufwändigere Kontrolle (manuell) einer vermeintlich erfolgreichen Datensicherung notwendig, täglich.

So schließt sich dann Apples neues Dateisystem erst einmal für Datensicherungen aus, finde ich für das Einsatzalter von APFS aber jetzt nicht besonders überraschend.

Meines Wissens (zumindest bei meinen Backups ist es so) legt Time Machine die Backups nach wie vor auf HFS-Formatierten sparse images an. Da ist das Problem daher nicht zu erwarten.
Siehe oben - ja, für selbstgebaute Backup-Systeme oder solche, die APFS-formatierte sparse images einsetzen (kennt jemand eines?) ist das ein ernstzunehmendes Problem. Das sollte man besser sein lassen. Time Machine ist, wenn sich seit meinem letzten neu angelegten Backup vor ein paar Wochen nichts geändert hat, nicht betroffen sein.

OK, Danke für die Antwort Das beruhigt erst einmal.
Ich hab nicht die geringste Ahnung, was ein "sparse image" ist, werde mich da mal einlesen...

Wenn Du ein normales Disk Image anlegst, ist es so groß wie seine Kapazität plus ein wenig Overhead, also für ein 10 GB-Image etwas mehr als 10 GB.

Wenn Du ein sparse image anlegst, dann ist es zunächst einmal sehr klein und wächst erst, wenn Du Daten hineinkopierst. Das hat den Vorteil, daß es eben im nicht gefüllten Zustand wenig Platz verbraucht, was bei Backups von Vorteil ist. Es hat den Nachteil, daß es durch die sukzessive Vergrößerung stärker fragmentiert über die Platte verteilt ist, und daß es, wenn es mit APFS formatiert ist, von besagtem Bug befallen ist ...

JA, lese ich auch gerade... danke.
Der Vorgang ist mir bekannt - nur mit dem Begriff konnte ich überhaupt nichts anfangen.. da ist mir wohl was durch die Synapsen gegangen (Altersbedingt )

ja, volle Zustimmung. Ich kenn' auch niemand, der APFS-formatierte sparse images einsetzt oder das z.Zt. will.
Bei Firmen mit heterogenen Systemen kenne ich BackUps per Script, und es ging mir um das Prinzip; die Vorteile von APFS wird man erst in späteren Versionen des FileSystems für Backups nutzen können.

Genau darauf hat Mike Bombich ja in seinem blog-post auch schon hingewiesen: (siehe: )