Confusione sui metadati | Forks con nome | Attributi estesi | Fork risorse - HFS +

Penso che ci sia una certa confusione generale sulla relazione tra tutti e quattro questi elementi sparsi sul web. Volevo chiarirlo.

1. Le forcelle nominate sono uguali agli attributi estesi ? In caso contrario, quali sono gli attributi estesi?
2. Il fork delle risorse è ancora implementato come fork o come attributo esteso ? Se è implementato in un altro modo, allora come?
3. I metadati memorizzati con un file (creatore, data di modifica ...) sono presenti relazioni o sovrapposizioni terminologiche tra gli altri tre citati. Un esempio potrebbe essere, gli attributi estesi sono solo coppie di metadati extra (chiave + valore) memorizzati su un file.

Qualsiasi risposta che possa chiarire come tutte e quattro queste siano correlate, in particolare per quanto riguarda le tre domande, sarebbe molto apprezzata e contribuirebbe a risolvere le controversie che vedo accadere attraverso risorse diverse.

La confusione deriva dal fatto che la relazione tra questi concetti è complessa e è cambiata nel tempo. Nei sistemi attuali la differenza tra un fork chiamato e un attributo esteso è in gran parte accademica.

Per un attributo esteso, i dati effettivi vengono archiviati nel set di dati dell'attributo.

Per un fork, ciò che è memorizzato è l'elenco dei blocchi di allocazione del disco che contengono i dati. Un fork di risorse è ancora un fork.

I metadati del file system di base sono archiviati in elementi dedicati del record del file system stesso, indipendentemente dagli attributi e dai riferimenti fork.

Non sono un esperto di questo, ma ho letto un po 'per cercare di capire cosa sta succedendo.

Direi "La confusione deriva dal fatto che:

• la relazione tra questi concetti è complessa e
• è cambiato nel tempo e
• Apple ha implementato sia API a livello di programma che strumenti come ls o cp sono in modo tale da nascondere molte delle differenze tra i concetti ".

AIUI, il file del catalogo HFS + contiene i record dei file di catalogo (tra le altre cose). Il record del file di catalogo contiene il normale tipo di informazioni sul file come la data di creazione, la data di accesso ecc. Il record del file di catalogo contiene anche due strutture che forniscono informazioni sulla posizione e le dimensioni del fork dei dati e del fork delle risorse.

AIUI, HFS + ha anche (copiato da Wikipedia HFS +) un "File di attributi [che] è un nuovo albero B in HFS Plus che non ha una struttura corrispondente in HFS. Il File di attributi può memorizzare tre diversi tipi di record da 4 KB: Record di attributi di dati in linea, record di attributi di dati Fork e record di attributi di estensione I record di attributi di dati Inline memorizzano piccoli attributi che possono adattarsi al record stesso I record di attributi di dati Fork contengono riferimenti a un massimo di otto estensioni che possono contenere attributi più grandi. utilizzato per estendere un record Attributo dati fork quando sono già utilizzati i suoi record di otto estensioni. "

AIUI, i dati memorizzati nel (o referenziati da) il File di attributi (sia in linea, Fork Data o Attributi di estensione) sono noti come Attributi estesi.

Quelle sono le strutture di dati, quindi come vengono utilizzate?

AIUI, le prime versioni del sistema operativo (possibilmente versioni precedenti alla 10.4 Tiger, che John Siracusa sembra indicare avessero apportato importanti cambiamenti in quest'area), indicavano il fork dei dati e il fork delle risorse dal file del catalogo.

AIUI, una volta arrivati ​​a 10.4 Tiger, il file degli attributi viene ampiamente utilizzato per archiviare tutti i tipi di dati.

È possibile (ma non lo so) che in 10.4 e successive, qualsiasi fork delle risorse sia indicato dal file degli attributi. Vale a dire in risposta alla tua prima domanda, direi che le forcelle denominate sono attributi estesi, a meno che non siano il fork delle risorse e il fork delle risorse sia referenziato dal file del catalogo.

Il problema nel sapere come vengono implementate le cose è che, al fine di preservare la compatibilità con le versioni precedenti, e probabilmente in particolare per supportare l'accesso ai file system scritti da una versione di Mac OS da un'altra versione, è necessario supportare in modo trasparente diverse cose e miscele di cose.

Non possiamo dire dai normali strumenti della riga di comando del Terminale dove sono effettivamente conservati i dati.

Pertanto, l'accesso a rsrcpotrebbe suggerire che si sta accedendo al fork delle risorse nel file del catalogo.

$ ls -l Icon^M/rsrc
-rwxr-xr-x  1 root  admin  486 23 Jul  2004 Icon?/rsrc

Tuttavia, sappiamo che sebbene Icon^Msi acceda alla sintassi come un file sotto la directory, non è proprio così, perché

$ ls -lR Icon^M
-rwxr-xr-x@ 1 root  admin  0 23 Jul  2004 Icon?

così Apple ha implementato un caso speciale per Resource Forks.

Se invece lo facciamo

$ ls -l@
-rwxr-xr-x@ 1 root  admin   0 23 Jul  2004 Icon?
    com.apple.FinderInfo    32 
    com.apple.ResourceFork  486 

Ciò suggerisce che stiamo accedendo al file degli attributi. Ma ancora una volta, l'implementazione di lspotrebbe avere un caso speciale per Resource Forks.

John Siracusa sottolinea qui che gli elenchi ACL sono memorizzati come "Attributi estesi", ma sono appositamente mascherati in modo da non essere visualizzati xattr. Quindi, di nuovo, c'è l'implementazione di casi speciali nell'implementazione di xattr.

(Si noti che questa elaborazione di casi speciali può essere nel codice dello strumento o nel codice delle API sottostanti a cui accedono gli strumenti.)

GregW, se vedi questo, sarebbe bello avere un'opinione più esperta sul fatto che io sia sulla buona strada o che sia confuso senza speranza.