Vor 4 Jahren habe ich auf einen Schlag – pragmatisch ja höchst sinnvoll, analytisch aber blöd – meinen Classic Mac Pro 5,1 auf Mojave, SSD und APFS umgestellt. Seitdem ist es mir jetzt das zweite Mal passiert, dass der Bootsektor unreparierbar zerschossen ist, sodass ich die SSD löschen und das System aus einem Backup neu aufspielen muss.

Das erste Mal hatte ich ein Sicherheitsupdate von Apple im Verdacht (die Details sind in diesem Thread dokumentiert), aber dieses Mal geschah es „einfach so“; nach einem Aufwachen aus dem Ruhezustand lahmte der Mac plötzlich enorm und als ich ihn deshalb neu starten wollte, ging das nicht mehr.

Das ist mir jetzt wie gesagt das zweite Mal innerhalb von 4 Jahren passiert, in den 19 Jahren davor nie.

Jetzt stellt sich die Frage, woran das liegt. An der SSD, an APFS oder an Mojave (oder am Zufall)? Ist natürlich alles Spekulation, aber mich würden Eure Gedanken und eventuelle Erfahrungen hierzu interessieren.

Was Bootsektor unreparierbar zerschossen im Detail heißt, habe ich am Ende des verlinkten Treads erläutert; macOS findet ein spezielles, unsichtbares Volume namens Preboot plötzlich nicht mehr, auf das bless aber Dateien kopieren müsste. Das kann weder vom Festplattendienstprogramm repariert werden noch durch die Auswahl des Startvolumes in den Systemeinstellungen (de facto also bless) behoben werden

In 24 Jahren mit Mac OS hatte ich nur einmal einen zerschossenen Bootsektor, das aber noch unter dem klassischen Mac OS auf einer HDD mit Hardwareschaden.

War eine prägende Erfahrung, seitdem lege ich Wert auf ein komplettes Backup.

In den folgenden Jahren (oder besser Jahrzehnten) habe ich viele Macs mit SSDs nachgerüstet, neue Systemversionen oder neue Dateisysteme aufgesetzt. Einen unreparierbaren Schaden an den Bootsektoren hatte ich nie wieder.

Beim Aufwachen aus dem Ruhezustand hatte ich allerdings schon häufiger Probleme, die durch einen Neustart allerdings (fast) immer zu beheben waren.
In der Regel waren nach dem Beenden des Ruhezustands Bluetooth-Geräte nicht mehr verfügbar.
Bluetooth läuft intern über USB.
Und es hängt von den ansonsten verwendeten USB-Geräten ab, ob es Probleme gibt. Speziell wohl von den dort verwendeten USB-Controllern bzw. Bridges...

Keine Ahnung, ob dir das hilft, aber du wolltest ja auch "Gedanken"

NVMe SSD oder SATA? Über PCIe-Karte oder direkt am SATA-Bus vom 5.1? Hatte das Problem mal mit ner PCIe für SATA-Karte in meinem 5.1....

Du benutzt ja ältere macOS-Versionen, trotzdem der Hinweis, dass mir unter Ventura(!) mehrfach Ähnliches durch die Kernel extension meiner Drobo 5D3 passiert ist. Auch bei mir half nur Neueinspielen aus dem Backup. Ich weiß nichr, ob Du irgendwelche Kernel extensions am Laufen hast, aber genau dorthin würde mein zweiter Blick gehen (nach der Hardwareüberprüfung).

PS.:
Im Fall des MacPro5,1 gibt es für die Verwendung von Mac OS 10.14 (Mojave) die Einschränkung, das eine "Metal-capable graphics card" eingebaut ist.
Sind alle von Apple verbauten "ATI Radeon HD 5770 or ATI Radeon HD 5870" wirklich "Metal-capable"? Hat da schon mal jemand untersucht?
Und sie sieht es mit geflashten Fremdkaren aus?

@weia
Welche SSD (Hersteller/Typ) und welche Firmware?

Wie du ja selbst vermutest kommen sehr viele Ursachen in Frage – von einer defekten SSD über einen Software-Fehler. Da es nur zwei Mal in vier Jahren aufgetreten ist, kannst du auch nicht anfangen, Komponenten auszuschließen – denn ich gehe mal davon aus, du wirst irgendwann den cMP in den Ruhestand schickst.

Was mir aber noch einfällt: Da nur Preboot weg ist, kommst du noch an die Logdateien auf der SSD dran? Du kannst ja den Zeitpunkt, an welchem es schief ging, recht genau eingrenzen. Vielleicht findet sich dort etwas, was zumindest den Übeltäter etwas eingrenzt?

SATA, direkt am SATA-Bus von 5,1 (in den Einschüben)Samsung SSD 860 EVO 4TB, Firmware von 2019, keine Ahnung, wie die heißt
Ja, klar, sonst würde Mojave ja gar nicht laufen. Ist eine Radeon RX 580 (ohne Modifikationen), wie von Apple empfohlen.
Ja, zwei, eine von MakeMKV, die andere, um den SMART-Status von externen Festplatten anzeigen zu können.

Ich hatte diese Details teils wegen Stresssituation nicht angegeben, teils, weil meine Überlegungen in mehr generische Richtung gingen.

Ja klar, ich kann die gesamte SSD problemlos lesen, Programme starten, Dokumente öffnen … nur booten kann ich nicht von Ihr.

Es gibt beim Scheitern des Bootvorgangs endlos viele Meldung der Form
Die sagen mir aber nix.

Soeben ist ein SuperDuper!-Backup der gesamten Platte fertig geworden, das fehlerlos durchlief und auch bootbar ist. Von der versuche ich jetzt zu booten, und wenn das geht, formatiere ich die SSD neu und spiel das Backup dorthin zurück.

Hab hier ne externe SSD per USB, die hatte ich auch schon in 2 Partitionen geteilt (APFS). Alle paar Monate war eine Partition zerschossen, beim letzten Male war auch die Partitionstabelle hinüber, oder wie das bei APFS nun auch heißen mag. Jedes mal hilft nur komplett neu formatieren. Ich habe sie nun nicht mehr partitioniert und seitdem ist Ruhe.
Das hilft jetzt wohl nicht weiter, aber Du bist nicht alleine mit solchen Zicken.

Weia
Du hast mich glaube ich falsch verstanden. Zu diesem Zeitpunkt, als dein Mac schlief ODER als er gerade aufgeweckt wurde, ist irgendein unbekannter Mist passiert. Es gilt, diesen Mist zu identifizieren.

Daher solltest du versuchen, von der (nicht bootbaren) SSD die Log-Dateien zu sichern und dort zwischen dem Zeitpunkt, als dein Mac funktionierte und dem Zeitpunkt, als er langsam wurde, verdächtige Log-Meldungen zu identifizieren. APFS-Fehlermeldungen, "Write failed…"....so was in der Art.

Jaja, das habe ich schon verstanden und gemacht. Es gibt aber keine Treffer zu APFS oder write darinnen und die einzigen Fehlermeldungen mit failed sind die schon geposteten (5 vor dem Ruhezustand, Hunderte danach).

Hier sind die kompletten 5 davor:
Die Hunderte danach sind alle von der schon geposteten Art. Den Ruhezustand habe ich kurz nach 5:25 Uhr aktiviert.

Von dem SuperDuper!-Backup konnte ich problemlos booten, also wollte ich es jetzt auf die interne SSD zurückspielen, die zuvor löschen wollte.

Aber das geht nicht. Das Festplattendienstprogramm spuckt folgende Meldung aus:
Sowas habe ich noch nie gesehen. Wie gesagt, ich kann auf diese SSD, d.h. die auf ihr installierten Dateien problemlos im Finder zugreifen, wenn ich von einer anderen SSD aus boote.

Weia
In welches Log guckst du denn da? Das "alte" system.log? Hat Mojave noch nicht dieses neue, komprimierte Log-Zeugs (Name fällt mir gerade nicht ein)?

Edit: Es heißt "Unified System Logs", Pfade gibts hier:

Zu den historischen Daten des Unified Logs gelangt man durch den Befehl log show im Terminal.
Die Konsole bietet nur den Einblick in live eintreffende Log-Meldungen. Und dieser Vorgang ist auf Mojave ohnehin noch ziemlich unterentwickelt.
Ich habe allerdings keine Erfahrung mit dem Zugriff durch log show auf die Log-Dateien eines anderen Systems.
Howard Oakley hat zahlreiche Erfahrungsberichte zum Thema Unified Log veröffentlicht.

Öh, ja. Die Unified System Logs finde ich so rätsel- wie grauenhaft und habe mich bislang noch nicht näher damit auseinandergesetzt. Das kann ich jetzt nicht auf die Schnelle machen.

Währenddessen hat sich mein Fokus ja auf die Frage verschoben, wie ich die Boot-SSD löschen kann, um von SuperDuper! das Backup aufzuspielen.

Währenddessen spielt SuperDuper! das Backup zurück auf die SSD. Die SSD konnte ich zuvor allerdings nur löschen, nachdem ich in die Wiederherstellungspartition gebootet hatte.

Weia
<Klugscheissmodus>Erstmal gucken, was kaputtgegangen ist, bevor man die Reparatur startet</Klugscheissmodus>

Ist mir klar, aber leider hat die Downtime gerade katastrophale Folgen für mich, so dass eine rasche Wiederherstellung absolute Priorität vor der Rekonstruktion eines absolut gesehen ja seltenen Fehlers hatte. Ein weiteres Nachforschen wäre ohne ein paar Stunden Schlaf zuvor einfach nicht mehr gegangen und so hätte ich weitere wertvolle Zeit verloren. Meine Backup-Platte ist eine HD; da dauert das Kopieren von 3 Terabyte einige Zeit (gerade ist etwa Halbzeit).

Außerdem glaube ich eher nicht, das SuperDuper! die Logdateien beim Kopieren auslässt.

Ich habe so ziemlich genau die gleiche Plattform wie Du, also Mac Pro 5,1 mit Mojave, Samsung-SSD (im unteren DVD-Schacht) mit APFS, Radeon RX 580. Das Problem ist bei mir noch nie aufgetreten. Ich weiß, das hilft nicht viel, aber ein Problem dieser spezifischen Hardware-macOS-Kombination ist es dann wohl eher nicht. Viel Glück mit der Wiederherstellung!

Log-Dateien des Unified Log muss man zügig sichern. macOS begrenzt die Menge. Ältere Einträge werden früher oder später gelöscht je nach dem in welcher Menge neue erzeugt werden. Ich glaube es wird auch ausgedünnt. Meldungen des Typs Info verschwinden eher als gravierendere Meldungen.

Es gibt inzwischen Samsung Magican für macOS:
Die Firmware die noch als ISO vorhanden ist wäre Samsung_SSD_860_EVO_RVT04B6Q_Mac.iso, die aktuelle Firmware kannst du jederzeit in den Systeminformationen unter SATA/SATA Express auslesen. Dort ist unter Modell die Version=Firmware gelistet.

Ja, das ist die von meinen Samsung-SSDs.
DriveDX zeigt das auch an. Ich habe ja entsprechende Programme, nur halt nicht auf meiner Notinstallation, auf der ich gestern war.

Info: Es läuft wieder, wenn auch manche Sachen in einem etwas chaotischen Zustand sind, der noch Detailarbeit erfordert. Ich bin jetzt unter immensem Zeitdruck und hoffe, ich kann später noch etwas posten.
Hab ich doch längst getan. Ich denke aber nicht, dass man daraus ersehen kann, was genau passiert ist, und ehrlich, ich habe ziemlich andere Sorgen im Moment.

Da habe ich gedacht "oh, endlich, muss ich haben". Also Samsung Magican installiert.
Die Software kann SMART auslesen und einen Benchmark durchführen. Firmware aktualisieren kann ich damit nicht.
Aber ...
Die Software möchte in den Datenschutzeinstellungen eine Freigabe haben.
Die Software startet automatisch beim Start des Mac.
Die Software wird als pkg installiert und im Programmordner sind nur 84 Byte. Die verweisen auf Library/Application Support. Dort sind 560 MB vergraben. 560 MB!
> Deinstalliert (mit UninstallPKG)

Ergänzung: In Application Support musste ich dennoch noch 2 Samsung-Verzeichnisse mit 595 MB löschen. Hat die Software Adobe entwickelt?

Ich würde die SSD vorsichtshalber tauschen ...
besonders bei einem Rechner, bei dem "eine Downtime katastrophale Folgen hat" (Zitat).

Gute Idee:
1 bootfähiges Backup auf externer SSD (z.B. Samsung SSD T7):
Kann man direkt an jeden Rechner stecken, booten und weiterarbeiten.

Verdammt, wie kriege ich den Dreck weg? Mit sudo rm -rf ... klappte nicht.

@marm
Auf welchem System (Hardware/macOS) hast du es installiert? Habe leider hier bei einem älteren System das Problem das sich die Software zwar installiert, aber überall nur NA zu sehen ist, was seltsam ist, denn es zeigt die aktuelle FW der SSD an, aber zu sonst nichts zu gebrauchen. Auf der offiziellen HP zu Magician ist die macOS Software noch nicht einmal erwähnt und in den FAQ wird sie auch verleugnet:Aktuell finde ich bei Samsung keine Info zu den Systemanforderungen bzgl. Apple macOS und getesteter Hardware, aktuell ist das Teil mit über 500MB lediglich ein total überdimensionierter Viewer für die Firmware Version für Leute die nicht wissen wo diese abgelesen werden kann.

Macbook Air M1 Sonoma RC. Von der Installation ist ganz dringend abzuraten.

Ist diese Datei regulär vorhanden? /System/Library/Extensions/AppleSamsungSerial.kext
Aber wie bekomme ich diese Kext-Erweiterung weg? /Library/StagedExtensions/Library/Extensions/SamsungMagicianPSSDDriver.kext

Übrigens musste ich in Application Support doch noch 595 MB von Hand entfernen trotz UninstallPKG.

Ok, es klappte mit
Ich brauche jetzt einen Kaffee ...

@weia
Besteht die Option auf eine NVME umzusteigen? Am besten auf eine Seagate FireCuda 510.

Ich denke eher, es liegt an APFS.

Nö, Null Platz.
Wieso gerade die?

Habe mit der FireCuda 510 sehr gute Erfahrungen gemacht. Vergleich mal die technischen Daten, die FireCuda ist speziell für Gamer und Performance entwickelt worden und hat 1300 TBW, die Samsung 980 z.B. nur 600 TBW bei gleicher Größe. Habe bis jetzt auch noch keinen Ausfall einer FireCuda 510 im Umfeld mitbekommen, bei den Samsung NVME jedoch schon 2 Defekte. Und die 860er/870er SATA von Samsung haben auch so ihre Probleme, da gab es Mitte 2010 auch eine Charge die reihenweise ausgefallen sind.
Daher die Frage. Aber wenn kein Platz, dann kein Platz.

So, hier zumindest eine Kurzversion dessen, was vermutlich passiert ist. Vermutlich, weil die Logdatei von 9 Stunden vor bis 2 Stunden nach dem Ereignis sage und schreibe 2,6 Millionen Einträge enthält und die wollte ich dann doch nicht alle lesen . Ich weiß nicht so recht, was das soll – zu viel Information ist dasselbe wie keine Information.

Wenn ich die Datei auf Vorkommen von APFS oder Error filtere, sind es immer noch 0,7 Millionen Einträge. 🙄

Jedenfalls tauchen einige Zeit vor dem Versetzen in den Ruhezustand Tausende Einträge folgenden Form auf:
Also ein APFS-Problem, wie ich vermutete. Das führt nun dazu, dass das Schreiben von Dateien teilweise fehlschlägt:
So tauchten z.B. einige während dieser Zeit geholte Mails zwar im Eingangs-Inhaltsverzeichnis von Mail auf, die Inhalte selbst aber fehlten (POP).

Und nun kommt mein Lieblings-Hassobjekt Nr. 1 unter Apples Unix-Modifikationen zum Tragen, die absichtlich völlig obskure /var/folders/-Hierarchie.

In der wird in irgendeinem Unterordner durch bless bei der Startdisk das versteckte Preboot-Volume gemountet. Durch die Schreibprobleme kommt es aber zu Inkonsistenzen bezüglich des genauen Mount-Ortes, dadurch funktioniert bless nicht und dadurch der Neustart.

Und wie kam es zu den APFS-Problemen? Angesichts von über 30.000 Einträgen der Form
(bevor die APFS-Probleme begannen), habe ich hier lsd in Verdacht, mein Lieblings-Hassobjekt Nr. 2 unter Apples Unix-Modifikationen (komplette Manpage: lsd provides various services for CoreServices frameworks. It is not meant to be invoked directly and it must not be terminated). Mit dem habe ich ohnehin enorme Schwierigkeiten (siehe LSD, lsd und die Launch Services) und ich hatte just vor dem Auftreten der Probleme einen abschließenden Beitrag in diesem Thread geschrieben, für den ich eigens die Launch-Services-Datenbank nochmals resettet hatte …

Jetzt habe ich aber von all dem die Schnauze gestrichen voll und mag mich nicht mehr weiter damit beschäftigen.

Dummerweise kann es immer noch ALLES sein, was den Fehler verursachte...du kennst ja jetzt nur die Konsequenz (kaputter btree), aber nicht den Auslöser.

Kleiner Rat: Wenn du auf deinen Mac angewiesen bist – kauf dir irgendeinen Backup-Mac, an dem du notfalls weiterarbeiten kannst. Jeder M-Mac sollte, wenns ein cMP tut, von der reinen Performance dicke ausreichen, so dass du deine Aufgaben weiter erledigen kannst.

Edit: Aber Danke für die interessante Rückmeldung zu dem Thema!

Es könnte auch ein schlicht unlösbarer Bug im APFS-Treiber vorliegen. Den pflegt Apple ja auch bei aktuelleren Systemen nicht parallel zum neusten OS. . Ich hatte früher auch mehrmals unlösbare Probleme mit APFS-Laufwerken samt vollem Datenverlust. Seit zwei Jahren habe ich Ruhe und ich fahre stets die aktuelle Version. Die haben dann andere Probleme, aber nicht solche Weltuntergänge.

Ja, so ist das bei Millionen Logeinträgen innerhalb von ein paar Stunden. Genau kann zumindest ich das nicht rekonstruieren. Aber einen begründeten Verdacht für den Verursacher habe ich ja geäußert. Wenn die Kombination Reset der Launch-Services-Datenbank und Bootsektor kaputt nochmals auftreten sollte, dann werde ich das mit Sicherheit bewusst wahrnehmen.

Apropos: Aus irgendeinem Grund war der Lint oben kaputt; hier nochmal: LSD, lsd und die Launch Services.
Das war nicht das Problem. Ich habe vier Macs, darunter einen eineiigen Zwilling meines Mac Pro. Das Problem waren die Daten, die ich nur auf diesem einen Mac Pro (und natürlich seinen Backups) habe. Wenn irgendwas anderes an dem Mac Pro kaputt wäre, könnte ich einfach den SSD-Einschub nehmen und im anderen Mac Pro einstecken (auch etwas, was ich an diesem Mac liebe) – aber es war ja eben der SSD-Einschub bzw. die Daten darauf, die kaputt waren.
Bitte.

Mein erster Gedanke bei "... - No such file or directory" war, ob Du auch bei APFS Unterscheidung von Groß-Klein-Schreibung verwendest. Ich kann mir Szenarien vorstellen, bei denen verschiedene Systemprogrammierer von Apple in ihrem jeweiligen Code z.B. unterschiedliche Camel-Case-Schreibweisen bei dynamisch zu erzeugenden Datei- oder Verzeichnis-Namen verwenden, der sich eigentlich auf die gleiche Datei oder das gleiche Verzeichnis beziehen sollte, es bei fehlender Unterscheidung von Groß- und Kleinschreibung letztendlich auch tut, aber bei APFS mit Unterscheidung dann nicht tut und deshalb dann "No such file or directory" auftritt. Das würde auch erklären, warum es bei mir nicht auftritt (verwende APFS ohne Unterscheidung) und es wäre auch plausibel in Hinblick auf vermutlich geringe Testhäufigkeit von APFS mit Unterscheidung von groß/klein seitens Apple gerade bei dem aus APFS-Sicht noch jungen macOS Mojave.

Danke für die Warnung zu "Samsung Magican"; ich war schon kurz davor es zu installieren Schön, dass Du es wieder losgeworden bist.

Selbstverständlich. Gerade bei APFS, das auf allen Apple-Betriebssystemen außer macOS ausschließlich case sensitive ist; lediglich bei macOS gibt es aus historischen Gründen noch case insensitive als Option. In Unix ist case sensitive eh Standard.
Kein macOS-Programmierer bei Verstand programmiert auf case-insensitiven Systemen; Systemprogrammierer bei Apple schon gleich gar nicht.
Falsch. Der quantitativ weitaus größere und zeitlich frühere Testfall war iOS und das ist case sensitive.

Die Annahme ergibt auch von daher keinen Sinn, dass ein aufgrund falschen Dateinamens nicht erfolgreicher Aufruf einer Datei natürlich niemals zu einer Korruption des Dateisystems führen darf. Wenn das passieren kann, ist das ein Fehler des Dateisystems.

Das ist ganz sicher kein Groß/Kleinschreibungsfehler. Falls tatsächlich die Reparatur der Launch Services Database die Schuldige ist, vermute ich irgendsowas wie eine race condition, die APFS zu schaffen macht, da lsregister ja in irrwitzigem Tempo das gesamte Dateisystem scannt.

ist dann iCloud Drive auch case sensitive? Zumindest für Anwender nicht und auch andere Systeme sind das nicht. Adobe-Programme mögen jedenfalls nicht so gerne ein System mit case sensitive Dateisystem, war zumindest vor Jahren so.

Ja, natürlich. Jedes moderne Dateisystem ist das.
Was meinst Du damit? Ich kann test.txt und Test.txt problemlos nebeneinander auf die iCloud verschieben.
Was für „andere Systeme“? Windoofs? 🤣
Ist auch heute noch so, weil dieser unglaubliche Sauhaufen von Firma es nicht fertig bringt, seine Dateinamen konsistent zu halten und statt das einmal zu fixen, sich bis heute nicht zu blöd ist, die Installation auf case-sensitiven Dateisystemen im Installer zu unterbinden. Das sagt eigentlich alles über die Code-„Qualität“ dieses Unternehmens; kein anderes Unternehmen dieser Größe gibt sich diese Blöße. Ich würde mich nicht wundern, wenn Apple nur deswegen macOS noch nicht auf Default case sensitive umgestellt hat.

Kurze Frage: Hast Du TRIM für die SATA-SSD's aktiviert? Ohne TRIM kann es mit der Zeit zu Komplikationen kommen.

Ja.

Das überzeugt mich nicht und was Du schreibst ist teilweise irreführend. iOS hat erst seit 2017 APFS. Mojave kam dann im Jahr darauf auf den Markt. Passt also zeitlich. Ich habe nicht behauptet, dass der fehlgeschlagene Aufruf einer Datei zur Korruption des Dateisystems führt. Hier geht es um die eigentliche Ursache des Problems. Ich hatte mich auf die Fehlermeldungen Deines Systems bezogen, wonach die Dateien nicht gefunden werden: das ist sicherlich nur eine Folge und nicht die Ursache, dennoch bemerkenswert. Dass "Kein macOS-Programmierer bei Verstand auf case-insensitiven Systemen" programmiert ist einfach unsachlich und zudem falsch. Auf dem Niveau habe ich keine Lust mich an der Fehlersuche zu beteiligen.

Ah, interessant. Dann liegt das an meinen Apps, die solchen Unfug verhindern und dann einen Zahl zur neuen Datei hinzufügen. Ich gehöre zur Fraktion "Ich will mir nicht auch noch die Schreibweise meiner Dateien merken müssen".

Was bedeutet, dass APFS case-sensitive 1 Jahr in tatsächlichem Einsatz millionenfach geprüft war und nicht, wie Du schriebst, mit vermutlich geringe[r] Testhäufigkeit von APFS mit Unterscheidung von groß/klein seitens Apple. Ganz im Gegenteil, APFS war vor Mojave nur in der case-sensitiven Version im tatsächlichen Einsatz geprüft worden. Es war APFS case-insensitive, das mit Mojave Premiere hatte und daher geringere Testhäufigkeit aufwies.
Wenn der btree kaputt ist , ist es genau das, was zu erwarten steht.
Es ist flapsig formuliert, aber sachlich richtig.

Jeder Programmierer läuft Gefahr, dass sein Programm auf derjenigen Kapitalisierungsversion des Dateisystems, auf der er nicht entwickelt, eine höhere Wahrscheinlichkeit von Fehlfunktionen aufweist (ja, er wird, wenn er vernünftig arbeitet, auch auf dem jeweils anderen Dateisystem testen, aber das erreicht faktisch kaum dieselbe Gründlichkeit).

Und jetzt vergleiche, was jeweils passieren kann:

Case-Insensitive für die Entwicklung, Case-Sensitive beim Nutzer:
Wenn der Entwickler bei der Kapitalsisierung seiner Dateinamen versehentlich nicht konsistent ist, werden beim Nutzer bestimmte (Ressource-)Dateien im Programmbundle nicht gefunden und das Programm funktioniert nicht, während es beim Entwickler funktioniert und unentdeckt bleibt.

Case-Sensitive für die Entwicklung, Case-Insensitive beim Nutzer:
Wenn der Entwickler für 2 unterschiedliche (Ressource-)Dateien im Programmbundle 2 Dateinamen verwendet, die sich nur durch die Kapitalisierung unterscheiden, wird beim Nutzer die eine Datei die andere bei der Installation überschreiben und das Programm funktioniert nicht; allerdings wird bereits beim Installationversuch eine Fehlermeldung des Typs Die Datei xy kann nicht kopiert werden, da sie bereits vorhanden ist ausgegeben.

Jetzt sage mir: Was ist wahrscheinlicher?

• Ein Entwickler auf APFS case-insensitive benennt eine Ressource-Datei aus Versehen datei.txt im Dateisystem, aber Datei.txt an zumindest manchen Stellen des Quellcodes und stößt beim kurzen Test auf APFS case-sensitive nicht auf die Funktion, die deshalb nicht funktioniert. Er veröffentlicht das Programm.
• Ein Entwickler auf APFS case-sensitive benennt zwei unterschiedliche Ressource-Dateien bis auf die Kapitalisierung gleich und stößt beim Versuch, das Programm kurz auf APFS case-insensitve zu testen, schon bei der Installation auf eine Fehlermeldung. Er veröffentlicht das Programm aber trotzdem.

Eben.
Ich hatte die Fehlersuche angesichts einer Logdatei mit 2,6 Millionen Einträgen, eines für mich plausiblen Verdachts bezüglich der Ursache und eines alle Jubeljahre auftretenden Fehlers bereits für mich für beendet erklärt:

Wie wär’s damit, einfach immer die korrekte Rechtschreibung zu benutzen?

Würdest Du auch wollen, dass für das Dateisystem Fotos und Photos dieselben Ordner und “quotation”.txt und "quotation".txt dieselben Datein sind?

Und hieltest Du Winter.rtf und winter.rtf vom Namen her für eine Datei mit identischem Inhalt?

Ich erkenne keinen Rechtschreibfehler, hilf’ mir auf die Sprünge. Falls du die Anführungszeichen meinst, sind das allenfalls Zeichensetzungsfehler. Ich könnte die automatische Ersetzung einschalten, die stört dann aber bei Diensten, wo ich Code eingebe.

Auf meinem Mac gibt’s sogar den Ordner Bilder, der eigentlich Pictures heißt 😉. Mir geht es hier im Buchstaben. F und f sind dieselben Buchstaben (nicht Glyphen), F und P nicht. Auch ist “ ein anderes Zeichen als ". Apropos Rechtschreibung: Dateien schreibt mit e vor dem letzten n.

Wenn es diese zwei Dateien in einem Ordner gäbe, dann natürlich nicht. Aber da ich mangels CS-Dateisystem nicht in der Lage bin, so zu arbeiten und es auch nicht will, möchte ich, dass es egal ist, ob ich „cat winter.txt“ eingebe oder „CAT WiNtEr.TxT“. Ich empfinde das (also nicht das konkrete Beispiel 😉) als Arbeitserleichterung. Deswegen mag ich auch AppleScript. Wenn ich da versehentlich bei Variablennamen an der Shift-Taste kleben bleibe, ist das kein Drama. Der Script Editor vereinheitlicht die Schreibweise dann automatisch.

Für mich ist das näher an der gesprochenen Sprache. Da kann man die Schreibweise nicht hören. Natürlich mag ich den Effekt der besseren Lesbarkeit gegenüber der reinen Kleinschreibung. Ich nutze das auch bei Dateinamen, aber nicht beständig. Wenn's schnell gehen muss, lasse ich die Shift-Taste gerne auch mal weg.

Ich begrüße auch, dass es egal ist, ob ich ü oder ü eingebe. Kann nicht nachvollziehen, warum das Unicode-Konsortium beides erdacht hat.

Es währe auch sehr umständlich, wenn man eine Datei auf einem Laufwerk suchen muss. Sowie: Winter.pages, WinTer.pages, WiNtEr.pages.

Jetzt lass uns nicht über Nomenklatur debattieren. Du weißt, was gemeint ist: Konsistente Rechtschreibung nach Regeln, ob Duden oder meinetwegen Deine eigenen. Hauptsache konsistent.
Wir reden doch ausschließlich über Dateinamen im Zusammenhang mit Programmcode. Nur da kann das Problem auftauchen, dass Du die Ressource-Datei Test.txt nennst, aber im Code mit test.txt aufrufen willst. Ansonsten kannst Du Deine Dateien benennen, wie Du lustig bist, case-sensitive hin oder her.

Jede (zumindest jede gebräuchliche) Programmiersprache ist ohnehin case-sensitive und Du musst strikt auf die Schreibung von Variablennamen achten. Warum nur ist das dann ausgerechnet beim Namen aufzurufender Dateien so schwierig?
Richtig. Und den musst Du im Programmcode mit Pictures referenzieren und mit nichts anderem.
Darüber ließe sich trefflich streiten, da sie doch die Semantik eines Wortes ändern (Nomen ↔︎ Verb etc.), während etwa " ↔︎ “ das nicht tun. Aber es geht gar nicht um Buchstaben. Wenn Du nicht erinnerst und es Dir zu schwer fällt, nachzusehen, ob Du den Ordner Fotos oder fotos genannt hast, dann kann Dir das mit Photos statt Fotos genauso passieren.
Gnagnagna. Das ist ein Tippfehler und das weißt Du auch. Tippfehler machen wir alle (Mir geht es hier im Buchstaben ) – ich gerade besonders, weil ich von der Beta eines neuen Browsers aus schreibe, wo Editoren noch furchtbar klemmen. Glashaus, Schweine und so …
Ich wollte darauf abheben, dass ein solcher Fall Sinn ergeben kann (ist ein Real-World-Beispiel). Beide Dateien enthalten denselben Text zum Thema Winter, Winter.rtf auf Deutsch und winter.rtf auf Englisch.
Na, zumindest sind wir da beide konsistent. Für mich ist AppleScript ein grandios verunglücktes Konzept.
Das wäre mir neu.
ergibt bei mir bei der Ausführung im Skript-Editor
Aber Quellcode ist alles, nur keine gesprochene Sprache. (Die nachahmen zu wollen, ist genau der konzeptuelle Irrsinn von AppleScript. Wie man das sprachnah, aber richtig macht, zeigen Smalltalk und Objective-C.)
Du arbeitest aber nicht bei Adobe?