Hallo,

wir hatten das Thema hier ja schon ein paar mal … und da ich aktuell von fehlerhaft kopierten Dateien (zum Glück "nur" Audio-Dateien) betroffen bin, möchte ich gern mal darüber sprechen.

Vorab: Mir ist bewusst, dass eine Modernisierung eines Dateisystems sehr komplex und aufwendig ist.

Apple hatte das ja schon mehrmals gemacht, also von HFS (1985) zu HFS+ bzw. HFS Extended (1998) und letztlich zu HFS+ Journaled (2002).

Und dann kam ja auch noch die case-sensitive Variante HFSX, die im Arbeitsalltag des Durchschnitts-Anwenders aber keinen Sinn macht, da technische Inkompatibilitäten (allen voran mit der Adobe Produktpalette) vorprogrammiert sind.

Dazu kamen dann weitere wichtige neue Funktionalitäten in Mac OS X wie Access Control Lists, Hard Links, HFS+ Compression und schließlich sogar Logical Volume Encryption (FileVault 2).

Letztlich wurde das alles aber immer nur an das mittlerweile wirklich betagte, originale Hierarchical File System "angeflanscht" bzw. "drum herum" gebaut.

Was ich nicht nachvollziehen kann: Was ist so schwer daran, eine Prüfsummen-Kontrolle für Kopiervorgänge zu implementieren?

Klar, es würde das kopieren von Dateien/Ordnern sicher um einiges verlangsamen. Aber dafür hätte man Gewissheit, dass die Daten nicht "unterm Radar" korrupt werden!

Soll Apple von mir aus im Hinterstübchen an einem ultra-modernen und zuverlässigem HFS-Nachfolger basteln und ihn 2025 einführen.

Bis dahin könnte Apple aber bitte gern die Prüfsummen-Kontrolle für Kopiervorgänge im Finder implementieren, sprich ebenfalls an das alte HFS "anflanschen".

Oder?

PS: Tools wie ChronoSync oder Carbon Copy Cloner bieten checksums als Option, aber mir geht es eben um die normalen, alltäglichen Kopiervorgänge im Findern von OS X.

Alternativ könnte dieser unsägliche Saftladen ja mal die Qualität seiner Produkte ein wenig anheben …
Volle Zustimmung!

Das hat nichts mit dem Filesystem zu tun! Man müßte dazu in den Finder einen Kopiervorgang einbauen, der die Prüfsummen überprüft. Für die Shell gibt es hinreichend viele Tools die das tun.
Apple arbeitete bereits an einer Portierung von ZFS für OSX, und hat das Projekt eingestellt. Leider ist bei Apple Schickimicki mittlerweile wichtiger als elementare Dinge wie ein zuverlässiges Filesystem.

Das Filesystem auszutauschen ist ein riskantes Unterfangen und ich vermute, dass der Aufwand - an Programmiertagen und damit auch Geld - so hoch ist, dass man die Kosten dafür nicht mehr rechtfertigen kann. Was wärst du denn bereit extra zu zahlen für so eine Umstellung?

molinar: Liest Du Beiträge eigentlich auch, bevor Du sie kommentierst?

Dann hättest Du zumindest mitbekommen müssen, dass ich mir lediglich eine HFS-"Erweiterung" wünsche, welche Prüfsummen ermöglicht. Also (vorerst) kein komplett neues Filesystem.

Und ja, von mir aus kann OS X wieder alle 2-3 Jahre eine neue Major-Version erhalten (statt jährlich) und sogar wieder Geld kosten (statt kostenfrei angeboten zu werden) - wenn dadurch die Qualität der hausinternen Vorab-Tests und somit die Qualität des Endprodukts wieder steigt.

Sollte ein neues Filesystem bringen, dann bestimmt mit einer neuen Mac OS X Version.

2 Optionen:
Bei Apples Geheimhaltung-Strategie:
Müssten/ könnten sie zwangsläufig 2 verschiedene Mac os X Versionen (da 2 verschieden Filmsysteme) für 2-3 Jahre parallel anbieten, um den Programmieren Zeit zu geben.

Alternative:
Keine Geheimniskrämerei:
man macht solch ein Vorhaben Publik und involviert rechtzeitig die ganzen Softwareanbieter/Programmierer ein,
und gibt an "von heute an in 2 Jahren bringen wir das neue Filesystem mit Mac OS X xx dann ist HSF+ tot"

Bei Apples kleinem Marktanteil ist solch ein Vorhaben wahrscheinlich schwieriger als wenn
es Microsoft durchziehen würde.

Aber letztendlich hat Genug Geld um die Softwareanbieter finanziell auch zu unterstützen

Bleibt letztendlich nur die Frage:

Warum wird kein HFS+ Nachfolger "geboren"?

Keine Motivation? Kein Wille?

Vielleicht haben sie ihn aber auch schon, wer weiß...

Das ist kein gangbarer Weg bei einem neuem Filesystem. Apple müßte parallel zu HFs+ das neue FS einführen, so daß die Entwickler und Anwender das neue FS erstmal testen können. Wenn es sich als stabil etabliert hat, kann man das neue zum Standard FS machen, HFS+ bleibt natürlich weiterhin in OSX.

Mein Favorit wäre auch weiterhin ZFS für OSX, mit OpenZFS gibt es sogar einen Port für OSX.

Das wurde nicht wegen Schickimicki eingestellt sondern weil Oracle OpenSolaris eingestampft hat und damit die offiziellen Spezifikationen und Referenzimplementationen nicht mehr offen waren.

Ich dachte Steve Jobs und Larry Ellison waren dicke Freunde?

Da hätte SJ mal den LE anrufen sollen.

ZFS wäre ein Traum... Kommt nie von Apple.

ZFS ist sehr interessant, hat aber auch seine Tücken.

Ein Kollege berichtete mir von seinen Erfahrungen, er hat mit einem Team an der TU München ZFS über viele Monate (Jahre) intensiv im Server-Umfeld getestet, wobei es zu einigen wirklich fatalen Fehlern kam, welche nachweislich auf schwerwiegende bugs in ZFS zurückzuführen waren.

Ich muss fairerweise dazu sagen, dass dies nun schon eine Weile her ist - inwieweit die Entwicklung von ZFS seitdem weiter gereift und vorangeschritten ist, kann ich nicht wirklich beurteilen.

Dazu kommt, dass ZFS sehr hohe Anforderungen an die Hardware hat (u.a. die RAM-Ausstattung), im Idealfall handelt es sich dabei auch um speziellen Arbeitsspeicher für Server-Umgebungen, der durch verschiedene Techniken hohe Ausfallsicherheit garantiert sowie Fehler erkennt und vermeidet (die genauen Bezeichnungen dieser Techniken sind mir auch nicht geläufig, aber es gibt sie, u.a. von IBM).

Jedenfalls hat das alles nichts mit normaler Consumer-Hardware zu tun, wie wir sie derzeit noch in sämtlichen Macs nutzen.

FreeNAS setzt ja auch auf ZFS, wobei dann auch nur das erhebliche teurere TrueNAS wirklich interessant ist.

Also wie gesagt, ZFS schön und gut, aber so richtig traue ich persönlich dem Braten (noch) nicht.

Von daher eben auch meine Idee, Checksums einfach an HFS+ "anzuflanschen", also so wie Apple es bei HFS auch schon mit vielen weiteren Features in der Vergangenheit getan hat.

Auch wenn ich sonst gerne bei Schelte gegen Adobe dabei bin, man muss nicht jeden Mist mitmachen. Und wenn ich sehe, was meine Kunden an Dateibezeichnungen verbrechen, würde ich mir wünschen ich könnte neben der Unterscheidung bei Groß- und Kleinschreibung auch noch die Verwendung von Leerzeichen, Umlauten und Sonderzeichen untersagen.


Zum Thema: Ein Kopiervorgang im Finder der funktioniert wie ditto, am besten auch noch mit drei Buttons zur Auswahl der Anzeige / Ausgabe ... *seufz* *träum*

jogoto: Ist witzig, dass Du das vorschlägst (ein Kopiervorgang im Finder mit einigen extra Optionen / Funktionen).

Als ich hier mal vor einigen Jahren vom Directory Opus und seinen Möglichkeiten unter AMIGA OS schwärmte und mir einige spezielle Funktionen in OS X wünschte, was glaubst Du, was das für einen Aufschrei hier gab - von wegen, so etwas brauchen wenn dann nur Power-User aber nicht der Durchschnitts-Anwender usw.

PS: Und nein, der Pathfinder bietet nicht das, was ich möchte. Dafür jede Menge Dinge, die ich tatsächlich nicht brauche.

Man könnte ja eine Tastenkombination einführen: Drag & Drop – "normaler" Kopiervorgang, Shift & Drag & Drop – Auswahl von Argumenten.

ZFS verbraucht nur mit der Option Deduplication sehr viel RAM, sonst hält sich das im Rahmen. Allerdings sollte man bei ZFS konsequent auf ECC setzen, da es sonst zu Problemen kommen kann. Meiner Meinung nach sollte ECC ohnehin Standard sein. RAM-Fehler sind einfach nicht zuerkennen ohne ECC Hardware. Von Intel gibt es passende CPUs und PCHs.

Insgeheim hoffe ich ja, dass Apple irgendwann ein HFS-NG (HFS New Generation) aus dem Hut zaubert.

Immerhin haben sie auch still und heimlich Swift entwickelt (von 2010 bis 2014) als zukünftigen Ersatz für Objective C. Das hatte auch niemand wirklich auf dem Schirm, oder? (Dass Apple eine komplett neue, eigene Programmiersprache entwickeln würde.)

Und so wäre es interessant mal zu recherchieren, ob in den letzten Jahren nicht eventuell ein ausgewiesener Experte wie Chris Lattner zu Apples Entwickler-Team gestoßen ist, der auf File Systeme usw. spezialisiert ist? Bzw. ob zumindest einer gesucht wurde?

Ich meine, Chris Lattner war immerhin der Chefentwickler bei LLVM und entwickelte dann auch Clang usw. (bzw. baute ein Team auf, dass dies umsetzt) – und er wurde bereits 2005 von Apple angestellt!

HFS-Experten gäbe es ja einige, zum Beispiel die Jungs von Paragon, die u.a. auch einen HFS+ Treiber für Linux entwickelten:

Oder der direkte Mitbewerber Tuxera:

Außerdem die Entwicklermannschaft von Media Four, welche Mac Drive für Windows entwickeln:

Und nicht zuletzt die DiskWarrior-Enwickler von Alsoft:

Wobei ich erstaunlich finde, dass man kaum Informationen darüber findet, wer genau eigentlich für die Entwicklung von HFS und all seine späteren Erweiterungen verantwortlich zeichnet bei Apple? Weiß da jemand mehr?

Bzw. auch, wer bei Apple intern an ZFS arbeitete (und Apple mittlerweile schon wieder den Rücken gekehrt hat)?

GreenBytes hatten ja mal speziell für OS X eine ZFS-Implementation entwickelt (ZEVO), wurden dann aber 2014 von Oracle eingekauft:

Hier kann man noch die Infos zu ZEVO sehen:

Als Alternative bleiben deshalb zur Zeit nur OpenZFS on OS X:

Sowie das mittlerweile scheinbar etwas betagte MacZFS (Free ZFS for Mac OS):

Einen schönen Artikel zu ZFS und BTRFS gibt es übrigens bei Ars Technica, lesenswert:

Wie auch immer, bin mal gespannt, ob jemand etwas bezüglich "File System Experten bei Apple" herausfindet?

Apple hat doch genug Kohle um mal auf Einkaufstour zu gehen …

Nur dass das, was Du als Mist zu bezeichnen Dich hier offenbar anheischig machst, der Standard in Wissenschaft und bei Servern ist …

Wenn hier überhaupt etwas künstlich und unnötig aufgepfropft wurde, dann ja wohl die Case-Insensitivtät für Dummies und Legastheniker. Denn „von sich aus“ ist ein Dateisystem nunmal case-sensitiv.

In jedem Fall und ganz unabhängig von den Auswirkungen könnte man von Programmierern wohl das Einhalten elementarster Qualitätsstandards wie dem der konsistenten Schreibweise von Dateinamen erwarten (und nur daran, dass Adobe-Programmierer selbst das nicht hinbekommen, scheitert ja die Lauffähigkeit von Adobe-Programmen auf HFS+ Case-Sensitive).
Genau, am besten wieder zurück zu Dateinamen nur mit ASCII-Großbuchstaben, maximal 8 Zeichen lang! Was hast Du denn für Probleme Per definitionem ist kein in UTF8 minus '/' darstellbarer Dateiname ein „Verbrechen“ ( ).

Jedenfalls solltest Du dich zumindest entscheiden: sollen Deine Kunden nun weniger Freiheitsgrade bekommen (keine Leer- oder Sonderzeichen) oder mehr (Kleinschreibung = Großschreibung). Beides in einem Atemzug zu fordern, ist, öhm, etwas inkonsistent …
Was meinst Du denn mit Auswahl der Anzeige / Ausgabe?

PS: Hatte ich es doch zumindest richtig in Erinnerung, Apple sucht schon !!!seit 2013!!! oder genauer seit nahezu 500!!! Tagen einen "Senior File System Engineer" (die Stelle ist tatsächlich immer noch aktiv ausgeschrieben):



Bin mal so frei und kopiere hier die Anforderungen:

The File Systems Engineering team within Apple’s Core OS organization is seeking an exceptional development engineer with a passion for solving complex problems to work on state-of-the-art file system technologies for iOS and OS X.

Working on a core technology, you will have a major impact on the design and implementation of future of iOS and OS X. Your code will be constantly running on millions of Apple platforms, including Macs, iPhones, iPads, and other devices. The ideal candidate is a proactive and hardworking software engineer who wants to take ownership and responsibility for developing best-of-class file system features in a fast paced environment while maintaining aggressive schedules. The ideal candidate will combine the ability to see and communicate big-picture issues, yet also have a passion for detail. We have a small nimble team which fosters innovation, rapid product iteration, teamwork, and feature delivery.

Key Qualifications

Required Experience:
Highly professional with the ability to multitask and deliver solid work on tight schedules
In-depth knowledge of file system internals
A genuine passion for operating system technology
Demonstrated creative and critical thinking capabilities and troubleshooting skills
Industry exposure and knowledge of file systems and UNIX kernel internals

Description

Responsibilities
Work with a highly skilled engineering team in the design and implementation of CoreStorage and future file system technologies
Drive product features and functional/industry specifications* Design, develop, debug, and test
Performance analysis and debugging
Represent the team in industry events, technical and product meetings
Work with cross functional teams to deliver features for desktop and embedded products

Education

MS in Computer Science or equivalent experience/skills

Additional Requirements

Preferred Experience:
OS X development
File system development experience
UNIX and VFS
SSD storage systems

Zwar off-topic, aber trotzdem: Swift ist nicht als Ersatz für, sondern als Ergänzung von Objective-C gedacht.

Im Kern ist Cocoa in C implementiert (CoreFoundation), das dann auf Objective-C gebridged wird. Da Swift nicht direkt mit C kann, kannst Du auch nicht auf Objective-C verzichten, genauso wenig wie auf C selbst.

Bislang hatten wir

C → Objective-C

und in Zukunft halt

C → Objective-C → Swift.

Swift ist eine Sprache für eine ganz bestimmte Anwenderklientel (die C nicht braucht, gerne Mainstream-Syntax und starkes Typing möchte und nicht allzu tief einsteigen will).

Ups, da habe ich wohl den wichtigsten Satz übersehen, wie peinlich ...

Für diese Stelle werden keine Bewerbungen mehr angenommen.

Also muss ja jemand gefunden worden sein, aber wer? Und was ist über diese Person bekannt?

Weia: Ah ok, verstehe. Bin halt kein Programmierer, daher meine Unkenntnis bezüglich Swift.

Au Weia

Wenn etwas in Wissenschaft (Profis) und bei Servern (hoffentlich von Profis) Standard ist, bedeutet das noch lange nicht, dass es auch für die Allgemeinheit geeignet ist und wenn die Fehleranfälligkeit bei Nichtprofis zu hoch wird, ja dann ist mir der kleinste gemeinsame Nenner am liebsten, selbst wenn der dann ASCII-Großbuchstaben, maximal 8 Zeichen lang + Endung bedeutet.
Und ich habe keine Probleme, danke der Nachfrage. Aber vielleicht Du, meinst Du in anderen Meinungen ein Problem zu erkennen. Denn nichts anderes ist es: meine Meinung. Freiheit bedeutet Verantwortung, Verantwortung setzt Wissen voraus. Kein Wissen um die Problematik manch kunstvoller und ausschweifender Benennung von Dateien oder Ordnern in System und Programmen = keine Verantwortung = besser keine all zu große Freiheiten. Übrigens eine Meinung, die bei einer Umfrage unter Admins sicher hohe Zustimmung erfährt.

Zu Auswahl der Anzeige / Ausgabe: ditto kann durch Argumente (Optionen) verschiedene Anzeigen / Ausgaben im Terminal erbringen. Da man bei einer GUI wie dem Finder von niemand verlangen kann Argumente einzugeben / überhaupt zu kennen, müsste das per Button erfolgen, wie bei einem Sichern-Dialog.

Vereinfachungen für Nicht-Profis können natürlich sinnvoll sein, ich habe auch nichts anderes behauptet.

Warum allerdings rigide technische Einschränkungen à la
eine Vereinfachung für Nicht-Profis sein sollen, wird wohl Dein Geheimnis bleiben. Ich kenne nur Anwender, die diese „technischen“/„unnatürlichen“ Einschränkungen seinerzeit verflucht haben. Warum kann ich die Datei nicht März1992 nennen? Warum muss ich statt Einkaufsliste für Geburtstag Schwiegermutter meine Datei EKLfGbSM nennen?
Könnte es am Ende sein, dass Du gar nicht die Einfachheit für Anwender, sondern für Dich als Admin/Programmierer im Kopf hast (der dann in seinen Skripten/Programmen mit UTF8 etc. korrekt umgehen muss)?
Es ist genau umgekehrt. Ich habe mich in keiner Weise dafür ausgesprochen, die von Dir präferierte Option (HFS+ Case-Insensitve) zu streichen. Ich habe nur gesagt, dass ich gerne auch die Option auf HFS+ Case-Sensitve behalten möchte (einschließlich der Unterstützung durch Drittanbieter). Diese mir wichtige Option hast Du mit den wenig schmeichelhaften Worten letzter Mist bedacht, den Programmhersteller daher nicht mitmachen müssten.

Wer hat nun also mit der Einstellung des anderen ein Problem?
Dieses Wissen fehlt mir in der Tat. Kannst Du mich aufklären, worin die Problematik 100 Zeichen langer Ordnernamen mit diversen Sonderzeichen besteht?
Dacht ich’s mir doch: Dir geht es gar nicht um Einfachheit für Anwender, sondern für Admins! Neee – die sollen für ihr Geld ruhig schuften und es den Anwendern einfach machen!
Ich kapier’s immer noch nicht: ditto kopiert Dateien; was für Anzeigeoptionen willst Du denn bei einem Kopiervorgang im Finder haben? Grüne, gelbe oder blaue Fortschrittsbalken?

Die Fehleranfälligkeit durch die HFS+ typischen Einschränkungen sind sehr hoch, weil UNIX nun einmal dafür ausgelegt ist auf einem Filesystem zu operieren, welches case sensitive ist. Es gab auf OSX schon Exploits wegen dieser Problematik!

Es wäre ein leichtes Cocoa so zu erweitern, daß die Dateidialoge solche Probleme abfangen. Wer also nur Cocoa Programme nutzt würde niemals in die Verlegenheit kommen Dateien zu sehen, die sich nur in der Großkleinschreibung unterscheiden.

Auch das / ist erlaubt. Der Finder unterbindet nur den Doppelpunkt. Ist aber vom Dateisystem her auch erlaubt.

Nur kommen leider viele Programme nicht mit dem / im Datei- order Ordnernamen klar.

Nö, ist es (technisch) natürlich nicht, wie sollte sonst der Pfadname eindeutig abgetrennt werden? Ein unzulässiges Zeichen, das dann als Pfadtrenner interpretiert wird, muss es geben. Der Finder und der Sichern-Dialog übersetzen jedes eingegebene '/' nur automatisch in ':'. Kannst Du dir im Terminal anschauen.
Weil er den wiederum auf das verbotene '/' mapped …
Klar, ':' wäre aus Unix-Sicht erlaubt (und ist im Terminal daher wiederum möglich).

Dieses Tohuwabohu ist leider ein unseliges Erbe aus dem holprigen Übergang Classsic Mac OS → OS X. Im Classsic Mac OS war ':' der Pfadtrenner, in Unix ist’s aber '/'. Da Apple meinte, seinen Classsic-Mac-OS-Nutzern ein Umdenken von ':' auf '/' nicht zumuten zu können, wurde stattdessen dieser irrsinnige Übersetzungsmechanismus eingebaut.

In allen Carbon-Programmen (samt dem alten Finder) konntest Du, wenn in einem Info-Fenster oder sonstwo Pfadnamen angezeigt wurden, stets noch lesen: Pfad:zu:meiner:Datei. Im Cocoa-Finder (und in allen Cocoa-Programmen) sah das dann plötzlich so aus: Pfad/zu/meiner/Datei

Im Low-Level-Code zur Ansteuerung von HFS+ wird dann vermutlich '/' wieder auf ':' zurückgemapped und vice versa … (denn HFS+ stammt ja schließlich aus der Classic-Mac-Welt).

Du vergisst, dass der Admin gerufen wird, wenn der Anwender nicht mehr weiter kommt. Natürlich ist die eigentliche Ursache unzulängliche Hard- oder Software aber diese Unzulänglichkeiten könnte man als Anwender entweder mit dem Wissen darum oder durch Einschränkungen begegnen.
Als Admin habe ich keine Probleme mit den Unzulänglichkeiten von Hard-, Software oder Anwender umzugehen, es wäre für die Anwender nur frustfreier, wenn sie nicht die Freiheiten hätten, die an anderer Stelle zu Schwierigkeiten führen.