Linus Torvalds e il filesystem OS X.

Nel 2008, Linus Torvalds ha affermato in un'intervista che "OS X in qualche modo è in realtà peggio di Windows per cui programmare. Il loro file system è completo e assolutamente schifoso, il che fa paura." Ho cercato maggiori dettagli sul perché si sente in questo modo sul filesystem OS X (presumibilmente HFS +) ma non sono riuscito a trovare nulla.

A Linus sicuramente non piace il modello base di filesystem Unix, e dubito che odia HFS + per la distinzione tra maiuscole e minuscole. E nonostante quanto provocatorio sia il suo commento, dubito che sia completamente senza merito. Poiché il commento era nel contesto della programmazione per OS X, sospetto che la sua opinione potesse essere basata su prestazioni, solidità, interfaccia del sistema operativo o qualcosa del genere. Qualcuno sa quali lamentele avrebbe potuto avere Linus dell'era 2008 con HFS + dell'era 2008?

È disponibile una trascrizione della sessione "Domande e risposte" in cui Linus ha reso il commento , ma sembra che non gli sia stato chiesto di elaborare. Non sono sicuro che un'analisi più approfondita della sua opinione su HFS + sia stata scritta altrove.

Per qualcun altro analisi della questione, puoi dare un'occhiata alle recensioni su Mac OS X di John Siracusa. In particolare quello per Mac OS X Lion che ha una sezione intitolata " Cosa c'è che non va in HFS + ." Penso che il bit più saliente sia (enfatizzare il mio):

Concorrenza, metadati scritti nell'ordine corretto dei byte, precisione della data inferiore al secondo, supporto per volumi di grandi dimensioni e supporto dei file sparsi sono tutte caratteristiche comuni dei file system Unix. Mac OS X, ovviamente, è basato su una base Unix. Quando HFS + è stato trasferito dal classico Mac OS a Mac OS X, doveva essere esteso per supportare alcune serie minime di funzionalità previste dai file system Unix .

Alcune di queste funzionalità si adattavano facilmente, ma altre erano molto difficili da aggiungere al file system senza interrompere la compatibilità all'indietro. Un esempio particolarmente spaventoso è l'implementazione di hard link su HFS +. Per tenere traccia dei collegamenti reali, HFS + crea un file separato per ciascun collegamento reale all'interno di una directory nascosta a livello di radice del volume. Le directory nascoste sono un po 'inquietanti per cominciare, ma il vero spavento arriva quando ricordi che Time Machine è implementato usando collegamenti reali per evitare inutili duplicazioni di dati.

Il punto importante qui è che Mac OS X sta usando un file system che non è stato nemmeno progettato per un sistema Unix, è stato progettato per Mac OS classico e patchato per implementare le funzionalità di Mac OS X 10.0 mantenendo la compatibilità con le versioni precedenti. Apple ha successivamente implementato le funzionalità aggiuntive che ha ora in Mac OS X 10.7 (journaling, metadati, eventi del filesystem ...) utilizzando lo stesso approccio di patching piuttosto che un approccio di "progettazione da zero". Non sono sicuro di come spiegarlo non tecnicamente, ma potresti dire che tutte queste funzionalità aggiuntive si basano su una base classica di Mac OS che non è mai stata progettata per supportarle. Ciò significa che la soluzione non è buona come potrebbe essere. L'esempio che Siracusa continua a discutere è che la soluzione che Apple ha dovuto utilizzare per i collegamenti reali mentre si lavorava entro i limiti di HFS + è troppo sensibile ai guasti hardware, a cui si aggiunge il fatto che HFS + non è mai stato progettato per occuparsi dei dati integrità. Naturalmente, mantenere la compatibilità con il classico Mac OS era una limitazione desiderabile in Mac OS X 10.0 ma in realtà non lo è più in Mac OS X 10.7.

Anche se non sono un esperto del sistema operativo e ho appena iniziato a utilizzare OSX dopo essere venuto da Windows, mi considero un PowerUser in Windows e abbastanza competente in Linux. Provenendo da quello sfondo, sono rimasto sorpreso dal fatto che in un sistema operativo abbastanza moderno come OSX, il filesystem ha stranezze come il modo in cui i nomi dei file vengono "confusi".

Capisco che i problemi di Linus con HFS + derivano dallo stesso punto: da quello che ho trovato ricercando il problema, HFS + memorizza i nomi dei file utilizzando Unicode, ma quando un file utilizza caratteri "estesi" o NON ASCII (come á, é, í, ó, ú, ñ dallo spagnolo o cose come ü in tedesco), per cui Unicode fornisce 2 modi per codificare il nome, OSX "normalizza" silenziosamente la codifica al momento dell'archiviazione ... Non è un vero problema quando il il file è stato creato e utilizzato in OSX, ma quando si condividono informazioni con utenti di altri sistemi operativi, il fatto che il nome del file cambi, rende tutti i comportamenti strani ...

Caso in questione: ho seguito il mio lavoro "artefatti" (file, documenti, ecc.) In Subversion negli ultimi 8 anni. Quando mi sono trasferito su Mac, ho ottenuto il client SVN per Mac e dopo aver fatto un checkout delle mie directory pertinenti, ho scoperto che tutti i file con accenti sembrano mancare e un nuovo file con lo stesso nome appare come non versione. Scavando in esso, il problema è che il file IN nel file system è codificato Apple, mentre i dati nel repository utilizzano un'altra codifica Unicode (perfettamente valida e legittima) ...

Questo, a mio avviso, è una grave "manomissione" dei miei dati. Apple comprende entrambi i formati della codifica del nome file (l'accesso a una condivisione in Windows o l'utilizzo di una chiavetta USB da Windows mostra i nomi dei file corretti, ecc.) Ma al momento della creazione del file, si è deciso "conosce meglio" e ha semplicemente rinominato i file. ..

Ancora una volta, non qualcosa che la maggior parte degli utenti noterà - fino a quando non fanno una copia di un file, o lo rinominano, e lo rimettono in quello originale e finiscono con due file apparentemente uguali !!!)

John Siracusa e Dan Benjamin discutono alcuni svantaggi di HFS + in Hypercritical # 56 .

Si occupano della corruzione dei dati in HFS + e prendono in considerazione alcune delle funzionalità di ZFS.