• Apfeltalk ändert einen Teil seiner Allgemeinen Geschäftsbedingungen (AGB), das Löschen von Useraccounts betreffend.
    Näheres könnt Ihr hier nachlesen: AGB-Änderung
  • Das Monatsmotto Juli lautet -- Kitsch as Kitsch can -- Jeder von Euch kann dafür ganz individuell bestimmen, was für ihn Kitsch ist und ein Foto davon einsenden. Macht mit, traut Euch! --> Klick

So geht’s: macOS: Terminal-Befehl zur Deaktivierung der Meldung “nicht korrekt ausgeworfen”

Wuchtbrumme

Golden Noble
Registriert
03.05.10
Beiträge
21.789
Hallo Michael,

zuerst einmal vielen Dank!
Allerdings finde ich, Deine Erklärung bzgl. iOS und iPadOS steht im Gegensatz zu dem was Du zu macOS sagst. Will sagen: bei iPadOs und iOS ist Apple offenbar (und wenn ich Deinen Text richtig verstehe) in der Lage Dateisysteme und Schreibvorgänge so zu gestalten, dass ein Abziehen von USB-Geräten kein Problem darstellt? Bei macOS wird aber unterstellt, dass es nicht so ist. Nur weil dort eine Meldung kommt?

Oder muss ich es so interpretieren: Beide Systeme sind schon ähnlich in der Behandlung solcher Vorgänge, nur Apple ist zu doof unter iOS eine entsprechende Meldung auszugeben? Oder möchte den geneigten User nicht damit belästigen.
mein Satz "Ein iPad oder iPhone haben keine Fehler. " war sarkastisch und ich habe den Smiley vergessen. Deiner zweiten Interpretation würde ich daher eher zustimmen (was das Belästigen angeht), zur tatsächlichen Implementation kann ich nichts definitives sagen wie ich schon erklärte, das ist im Prinzip Empirie.
Noch was aus meiner Anekdotischen Evidenz: Ich beschäftige mich seit es USB gibt damit. Noch niemals sind mir durch Abziehen des Sticks (ohne Auswerfen) Daten verloren gegangen. Noch niemals hatte ich eine Meldung "nicht korrekt Ausgeworfen" wegen eines defekten Kabels oder Sticks. Ja, ich hatte defekte Kabel und USB-Sticks. Aber eine Meldung deswegen habe ich noch nie bekommen. Muss nichts heißen, aber hier ist es nun mal so.
darauf habe ich mich zwar nicht im Wesentlichen bezogen (weil Du ja bereits die verhaltensbezogene Meldung hinreichend angesprochen hattest und ich auf den Unterschied zu beobachtbaren technischen Ursachen für die Meldung hinweisen wollte), aber ich freue mich für Dich. Ich bin auch kein zwischengeschalteter Debugger, d.h. bei allen technischen Diskussionen ist ein wenig Kaffeesatzlesen dabei (wer hat schon die fehlenden Bytes auf einem Datenträger eindeutig einem Hauptspeicherinhalt und dann einem nicht stattgefunden habenden Schreibvorgang zuordnen können?), aber die Frage ist doch, will man das dem Enduser als Mantra verkaufen? "Zieh halt ab, Deine einzige Backupfestplatte!".
Das Ziel der verhaltensbezogenen Meldung ist es, den Benutzer anzuhalten, den Mechanismus des OS zum sicheren Auswerfen eines Datenträgers zu benutzen, der sicherstellen soll, dass alle Daten geschrieben wurden und das Dateisystem sauber geunmountet wird.
Ach und was mir noch einfällt: Apples Dateisysteme (auf neuen Geräten APFS) sind so genannten Journaling-Dateisysteme. Dieses sind wesentlich Fehlertoleranter, als ältere Systeme. Bei Apple gibt es Hauptsächlich HPF+ und APFS, die diese Funktion unterstützen. Wenn eine externe SSD damit formatiert ist, sollte es sogar beim Abziehen während des Schreibvorganges keine Probleme geben. Die Datei ist dann nur möglicherweise nicht vollständig und der Kopiervorgang sollte wiederholt werden.
mir sind die Funktionsweisen von Journalling-Dateisystemen bekannt. Lass mich zusammenfassen, dass weder HFS+ noch APFS einen plötzlichen Stromverlust während eines Kopierauftrags vergessen machen und um noch mal auf das vorhergehende Statement zurückzukommen, dass es die Meldung nicht bräuchte: macOS unterstützt auf Wechseldatenträgern auch nicht-Journalling-FS wie FAT oder HFS (ohne Journalling).

Im Prinzip müsste tatsächlich nur ein Replay des Logs notwendig sein, um wieder einen konsistenten sauberen Dateisystem-Zustand zu erhalten - was aber wiederum nicht heißt, dass all jene Daten da wären, die zum Zeitpunkt des Abziehens im Prozess des Schreibens waren. Da müsste man z.B. einen Quell-Ziel-Vergleich machen, denn die Quelle könnte sich bis zum Replay ja auch geändert haben, z.B. gelöscht worden sein. Jetzt muss ich ein wenig vorsichtig sein, weil ich die neusten Features von macOS nicht genau kenne - wer genau schaut, sieht, dass im Finder Kopieraufträge mit einem sich schließenden Tortendiagramm abgebildet werden und auch angehalten werden können. Ich kenne Journalling-FS so, dass sie quasi all jene Transaktionen notieren, die das von ihnen verwaltete FS betrifft. Inwieweit macOS das Journalling-FS von APFS oder HFS+ benutzt, um fehlgeschlagene Aufträge *selbsttätig* nachträglich zu reparieren - keine Ahnung. Bei ext4, xfs und NTFS bis XP wo ich das letzmalig verfolgt habe, war es IIRC komplett losgelöst. Der Anwender hätte den Fehler überhaupt erst selbst erkennen müssen, dann die Aktion wiederholen müssen. Und selbst wenn macOS das Kopieren verfolgen würde - wenn zwischenzeitlich eine noch nicht kopierte Datei der Quelle (und ich konstruiere mal) und alle Snapshots gelöscht würden, könnte es das auch nicht mehr tun.

Sei es wie es sei, hier gibt es noch mehr Variablen (Write-through, write-back, Eigenintelligenz und Caching des Datenträgers, ...), bei der Aktion des Rausziehens riskiert man schon ein unsauberes Dateisystem. Das wird per Default nicht von macOS gemountet, sondern zunächst geprüft - und oft genug kann es nicht wieder sauber gemountet werden. Schon das alleine wäre Grund genug, das nicht anders zu sehen.
 
Zuletzt bearbeitet:
  • Like
Reaktionen: Michael Reimann