Confusione sui metadati | Forchette con nome | Attributi estesi | Forchetta risorse - HFS +

10

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

  1. I named forks sono gli stessi di attributi estesi ? In caso contrario, quali sono gli attributi estesi?
  2. Il fork di risorse è ancora implementato come fork o come attributo esteso ? Se è implementato in un altro modo, allora come?
  3. I metadati archiviati con un file (creatore, data di modifica ...) esiste una relazione o una sovrapposizione terminologica tra gli altri tre menzionati. Un esempio potrebbe essere, sono attributi estesi solo extra coppie di metadati (chiave + valore) memorizzati su un file.

Qualsiasi risposta che possa chiarire in che modo tutti e quattro sono correlati, in particolare per quanto riguarda le tre domande, sarebbe molto apprezzata e contribuire a risolvere le controversie che vedo verificarsi attraverso risorse diverse.

    
posta rubixibuc 16.02.2012 - 07:23
fonte

2 risposte

5

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

Per un attributo esteso, i dati effettivi vengono memorizzati nel record 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 memorizzati in elementi dedicati del record del file system stesso, indipendentemente dagli attributi e dai riferimenti di fork con nome.

    
risposta data 16.02.2012 - 15:25
fonte
2

Non sono un esperto in 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 entrambe le API a livello di programma e strumenti come ls o cp sono un modo per nascondere molte delle differenze tra i concetti. "

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

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

AIUI, i dati memorizzati in (o referenziati da) il file degli attributi (sia inline, Fork Data o Extension Attributes) sono noti come Extended Attributes.

Quelle sono le strutture dati, quindi come vengono utilizzate?

AIUI, prime versioni del sistema operativo (possibilmente versioni precedenti alla 10.4 Tiger, che John Siracusa sembra indicare alcuni cambiamenti importanti in quest'area), ha indicato il fork dei dati e il fork delle risorse dal file Catalog.

AIUI, una volta arrivato a 10.4 Tiger, il file Attributi diventa ampiamente utilizzato per memorizzare tutti i tipi di dati.

È possibile (ma non lo so) che in 10.4 e dopo, qualsiasi fork di risorse viene indicato dal file Attributi. Cioè in risposta alla tua prima domanda, direi che le forcelle denominate sono attributi estesi, a meno che non siano il fork di risorse e il fork di risorse sia referenziato dal file di catalogo.

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

Non possiamo distinguere dai normali strumenti a riga di comando di Terminal in cui i dati vengono effettivamente trattenuti.

Quindi, l'accesso a rsrc potrebbe suggerire l'accesso al fork di risorse nel file di catalogo.

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

Tuttavia, sappiamo che sebbene la sintassi assomigli ad un file sotto la directory Icon^M a cui si accede, questo non è il vero caso, perché

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

quindi Apple ha implementato un caso speciale per le forcole delle risorse.

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 

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

John Siracusa sottolinea qui che gli elenchi ACL sono archiviati come "Esteso Attributi ', ma sono mascherati in modo speciale in modo che non vengano mostrati in xattr . Quindi, ancora una volta c'è l'elaborazione di casi speciali nell'implementazione di xattr.

(nota che questa elaborazione caso speciale può essere nel codice dello strumento o nel codice delle API sottostanti a cui gli strumenti accedono).

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

    
risposta data 01.07.2014 - 23:25
fonte

Leggi altre domande sui tag