Jo what ever.... die APE hat auch irgendwie eine art betriebssystem. da müsste man sowas auch implementieren. wenn eine lösng exsistiert dann sollte man die auch auf ein "leicht" anderes system übertragen können.
Der Aufwand steht in keinem Verhältnis zum Nutzen! Vor allem, da man das Problem einfach per Image-Datei lösen kann.
zudem spricht nix gegen eine echte weiterentwicklng von HFS+
Doch, denn man muss keine Weiterentwicklung von HFS+ machen (wie es Apple ja bereits getan hat), sondern ein neues Dateisystem entwickeln! Das Problem dabei ist, dass man nicht "einfach so" das Dateisystem austauschen kann, da gibt es zu viele Altlasten, die weiter bestehen müssen. So sind viele OSX-Programme zwingend auf die Funktionen/Eigenschaften des HFS+ Dateisystems angewiesen. z.B ist der Pfad-Separator in HFS+ ein ":" und nicht wie bei Unix üblich ein "/". Daher ist in HFS+ ein ":" im Dateinamen nicht erlaubt, aber ein "/" dagegen schon. Man müsste also diese Apps und vor allem die Daten/Dateinamen der User darauf anpassen! (Das Feedback der User möchte ich dann nicht hören.)
Und eigentlich gibt es momentan keinen zwingenden Grund das Dateisystem neu zu entwickeln, denn durch das Anflanschen der Hardlinks kombiniert HFS+ UNIX-Eigenheiten (Hardlinks) mit dem klassischen Mac OS Dateisystem und dessen Vorteilen (File IDs, multiple data streams pro Datei (Data Fork, Resorce Fork)). z.B. File ID wird auch bei Aliasen verwendet und daher kann OSX das Alias noch nach Umbenennen/Verschieben der Datei wieder auflösen.
Ich will ja auch nicht hardlinks auf jedes beliebiges netzaufwerk sondern nur auf Apple produkte! dann würde ich zwar auch rummosern warum es nicht für andere läuft, aber zumindestens apple sollte doch bei seinen eigenen produkten dazu in der lage sein das die entsprechend miteinander zuverlässig laufen.
Apple hatte ja schon erhebliche Schwierigkeiten es in den aktuellen Funktionszustand zu bringen. Und die aktuelle Hardlink-Problematik macht es schlicht unmöglich.
und ob ich nun in einem image hardlinks anlege das selbst auf einem netzlaufwerk ist, oder direkt auf dem netzlaufwerk... wo bitte ist da der unterschied. wenn die verbindung abreist ist das image auch beschädigt.
Das Volumen im Image wird lokal verwaltet und verhält sich, wie ein lokales Laufwerk. Auf das Dateisystem eines Netzwerk-Laufwerkes kann man aber nicht direkt zugreifen, sondern nur über das Übertragungsprotokoll (SMB oder AFP), d.h. OSX kann nur was per SMB oder AFP möglich ist und bekommt vom Dateisystem "dahinter" nix mit. Deswegen kann man ja auch übers Netzwerk auf NTFS-Festplatten (die in einer Windows-Rechner sind) schreiben, was lokal angeschlossen (mangels Treiber) eigentlich nicht funktioniert. Hardlinks werden von SMB gar nicht und von AFP nur lesend unterstützt.
Konsequent wäre dann auch eine image lösung für die lokale variante gewesen. zudem hätte man dann keine 2 unterschiedlichen verfahren entwickeln müssen.
Man musste keine zwei unterschiedliche Verfahren entwickeln! Eine Image-Datei verhält sich genau so wie eine lokal angeschlossene HD für OSX. Im Gegenteil: wenn man auf eine Netzwerkfestplatte hätte genauso schreiben wollen, wie auf eine lokale, müsste das AFP-Protokoll auch Hardlinks unterstützen.
jo aber solange die platte noch nicht voll ist hab ich kein bock dauernt neu zu starten. erstmal kostet das zeit und zum anderen... wer weiß eventuell brauch ich ja noch ne datei von dezember 2007
Natürlich ist das doof, aber es geht einfach nicht anders. Und das wird sich auch so schnell nicht ändern.
jo also aufruf an die findigen progger.... dann könnt ihr auch gleich die anderen punkte... programmiert doch mal bitte
Time Machine plus !
Niemand außer Apple kann das Dateisystem oder das Netzwerkprotokoll (AFP) dahingehend verändern, dass dein Problem gelöst wird.
jupp das klingt nach ner typischen Apple lösung! die idee ist angenommen!