Resource fork

La resource fork è una delle due parti di cui sono costituiti i file del sistema operativo Mac OS (l'altra è la data fork); la resource fork è usata per memorizzare dati strutturati, mentre la data fork contiene una semplice sequenza di byte, e corrisponde quindi al modello dei file di UNIX.

Il sistema dei fork è implementato su tutti i file system usati per i dischi di sistema del Macintosh: MFS, HFS e HFS Plus. Progettato originariamente da Bruce Horn per la prima versione del Mac OS, il sistema dei fork divenne immediatamente una caratteristica molto usata dai programmatori. Sebbene le resource fork siano usate prevalentemente nei file eseguibili (per esempio, per contenere le icone usate dall'applicazione), non c'è nulla nel sistema che restringa il loro impiego, e qualunque file può avere una resource fork. Per esempio, un word processor potrebbe memorizzare il testo di un documento nella data fork, e le immagini contenute nello stesso documento nella resource fork del file che memorizza il documento.

In altri casi, la resource fork viene usata per memorizzare metadati su un file (autore, icona, ecc.). Il file system del Macintosh dispone comunque di un'area separata per memorizzare i metadati, distinta sia dalla resource fork che dalla data fork, il cui accesso è particolarmente veloce. Tuttavia lo spazio disponibile in quest'area, che è incorporata nello spazio di memorizzazione delle directory, è alquanto limitato, e tipicamente contiene soltanto le date di creazione e modifica, il tipo di file e il codice del suo creatore, la lunghezza delle fork, e il nome del file stesso.

Alcuni tipi di file hanno soltanto una resource fork. Per esempio, i file eseguibili per Motorola 68000 contengono il codice eseguibile fra le risorse (con tipo 'CODE', codice). Al contrario, i file eseguibili per PowerPC memorizzano il codice nella data fork.

Dettagli sulla tecnologia Macintosh

Il sistema operativo del Macintosh offre numerosi servizi per l'interfaccia grafica. Molte delle strutture dati usate per questi servizi, e in particolare quelle usate per descrivere gli elementi della GUI come icone, menu e finestre, sono memorizzati in formati con strutture definite note come risorse. Le risorse sono memorizzate su disco nella resource fork del file che contiene l'eseguibile dell'applicazione relativa (o anche di un qualunque altro file, benché si tratti di un uso raro). Il sistema operativo del Mac consente l'accesso alla data fork con modalità analoghe a quelle degli altri sistemi operativi (apertura del file, spostamento a un offset indicato, lettura di dati sotto forma di sequenza di byte). Al contrario, l'accesso alla resource fork è più simile all'estrazione dei dati da un database: si indica a quale risorsa si vuole accedere, e il sistema operativo provvede a ricercarla nella resource fork del file e a caricarla in memoria.

Identificatori di risorse

Ogni risorsa ha un identificatore di tipo detto OSType (un valore memorizzato in 32 bit, solitamente rappresentato come una serie di 4 caratteri ASCII) e un identificatore unico detto ID (un valore memorizzato come un intero con segno a 16 bit), nonché — opzionalmente — un nome. Esistono codici standardizzati per i tipi più comuni, fra cui:

"DITL" per le finestre di dialogo;
"PICT" per le immagini;
"snd" per i campioni audio;
"CODE" per il codice eseguibile;
"WDEF" per il codice di definizione delle finestre;
"MDEF" per il codice di definizione dei menu;
ecc.

Ciascuna applicazione può poi definire i propri tipi per memorizzare altri tipi di dati. Esistono strumenti di utilità come ResEdit che consentono all'utente finale di modificare le risorse usate dalle applicazioni o dallo stesso sistema operativo, modificandone così l'aspetto e, entro certi limiti, il comportamento.

Le applicazioni accedono alle risorse semplicemente fornendo al sistema operativo il loro OSType, ID o nome; il sistema restituisce l'indirizzo di memoria (nello heap) in cui la risorsa è stata caricata. Una caratteristica particolarmente interessante del sistema delle resource fork è che il componente del sistema operativo che si occupa del loro caricamento, il Resource Manager, mantiene uno stack di tutte le resource fork aperte, e ricerca le risorse richieste in tutto lo stack, partendo dall'elemento in cima (che tipicamente è la resource fork dell'applicazione) e proseguendo, finché la risorsa non viene trovata, con gli elementi più in basso nello stack (tipicamente, le varie resource fork dei componenti del sistema operativo). In questo modo, le applicazioni possono cambiare, per esempio, le icone o i font usati per default semplicemente fornendo nel proprio resource fork delle risorse alternative con lo stesso ID o lo stesso nome. Inoltre, con questo meccanismo il modo con cui vengono caricate le risorse è indipendente dalla effettiva posizione delle stesse, e dal loro "proprietario" (siano esse risorse dell'applicazione o del sistema). Esistono tuttavia delle ID riservate e delle chiamate di sistema che permettono alle applicazioni di modificare le modalità di ricerca delle risorse.

Problemi di compatibilità

La suddivisione dei file in due fork ha sempre causato problemi di compatibilità con altri file system. Per inviare un file Macintosh attraverso una rete o un altro mezzo (nastri, dischi, ecc.), la data fork e la resource fork devono essere serializzate insieme, in modo da ottenere un unico file. Tuttavia, questa operazione rende anche i file contenenti tipi di dato standardizzati (per esempio, un testo ASCII) incompatibili con l'equivalente file UNIX o Windows. Sono stati sviluppati negli anni numerosi formati specializzati, fra cui MacBinary e BinHex che definiscono il modo in cui questa serializzazione viene fatta; naturalmente, è poi necessario un tool corrispondente per trasformare il file serializzato in un nuovo file con due fork (sul Mac) o in due file distinti, contenenti ciascuno una delle fork (altri sistemi). Lo stesso problema si verifica con il file server di rete; tipicamente i file server UNIX aggirano l'ostacolo memorizzando le resource fork dei file scritti da un Mac in una directory nascosta.

Fino all'uscita di macOS v10.4, i comandi UNIX forniti dal Mac OS X (come cp e mv) non rispettavano le resource fork, che venivano così perse — in alcuni casi distruggendo in effetti il file. Erano tuttavia forniti altri comandi, distinti da quelli standard, per compiere le stesse operazioni.

Altri sistemi operativi

Il concetto di risorsa è ormai di uso comune in tutti i moderni sistemi. Nonostante ciò, il concetto di resource fork rimane legato solamente ai sistemi Mac. La maggior parte dei sistemi utilizzano un file binario che contiene le risorse, che viene poi "attaccato" alla fine di un file di programma già esistente. Questa soluzione è utilizzata in Microsoft Windows, per esempio, e soluzioni simili vengono utilizzate con sistemi X Window, anche se spesso le risorse vengono lasciate in un file separato.

Nonostante il formato NTFS di Windows NT possa supportare le fork (e quindi possa essere un file server per file Mac), la caratteristica che fornisce tale supporto, chiamata "alternate data stream", non è mai stata utilizzata intensivamente e sicuramente mai come una vera resource fork. Comunque, le caratteristiche del sistema operativo Windows (come il pannello standard Sommario nella pagina delle proprietà per file non-Office) e i programmi Windows le stanno utilizzando più spesso adesso, e Microsoft sta sviluppando un file system di nuova generazione che ha questa caratteristica alla sua base.

Le prime versioni di BeOS implementavano un database integrato nel file system che poteva essere usato in maniera analoga al resource fork. Problemi di efficienza portarono a modificare questo approccio nelle release successive ad un sistema più complesso di attributi del file system. Mediante questo sistema le risorse venivano gestite in modo più simile a quanto avviene nel Mac.

AmigaOS non fa uso dei fork e resource. Il formato eseguibile di Amiga spezza il file eseguibile in tanti hunk o grosse porzioni di dati dove sono presenti di seguito, codice e dati, alcuni tipi validi di hunk sono: HUNK_UNIT, HUNK_NAME, HUNK_CODE, HUNK_DATA, eccetera. L'eseguibile viene riconosciuto tramite un magic cookie $000003f3 posto all'inizio del file, detto anche in Unix magic number. Di seguito viene il numero di hunk in cui è composto il file, il numero progressivo degli hunk partendo da 0 e infine, prima che inizino gli hunk veri e propri vi è la tabella con la grandezza dei vari hunk presenti nel file eseguibile. Amiga registra anche dei metadati in file noti come .info (dal nome della loro estensione), sebbene non siano esattamente equivalenti ai resource fork. Ad esempio: salvando un progetto su disco, vengono salvati due file, MyProject e MyProject.info. In MyProject saranno registrati i dati veri e propri del progetto, mentre in MyProject.info saranno contenute, l'icona del progetto, e l'informazione riguardante quale programma è quello originale (oppure quello preferito dall'utente) per aprire il progetto (in AmigaOS non esiste l'application binding), inoltre le opzioni particolari del progetto ed i commenti dell'utente. I file .info sulla scrivania dell'Amiga non appaiono come file a sé ma l'icona stessa, estratta dall'interno dell'info cui si riferisce, essendo visibile sulla scrivania, è il medium che interconnette fisicamente l'info con il file dati che gli appartiene. La pressione del tasto destro del mouse sull'icona, apre una finestra di input che permette di leggere o modificare i metadati. Per visualizzare i file info come file a sé, questi devono essere visualizzati usando la riga di comando o tramite un file manager. L'utente può anche fare a meno del file info, cancellandolo, rinunciando però alla comodità dell'icona e dei metadati. I cloni moderni dell'Amiga (AROS, MorphOS e AmigaOS4.0) possono anche accettare file grafici standard PNG come immagine dell'icona del file .info.

Forse la migliore soluzione al problema è stata implementata sul sistema operativo NeXTSTEP e sul suo successore macOS, oltre ad altri sistemi come RISC OS. In questi sistemi le risorse sono lasciate nella loro forma originaria, ad esempio le immagini, anziché essere codificate in qualche specie di contenitore, sono incluse come interi file TIFF. Le risorse vengono poi poste in un direttorio usando un file system Unix assieme al codice eseguibile. Il direttorio, chiamato bundle (pacchetto), viene poi presentato all'utente come l'applicazione stessa.

Questa soluzione fornisce tutte le funzionalità della resource fork, ma permette una facile manipolazione delle risorse da qualsiasi applicazione, non è più quindi necessario un editor delle risorse come ResEdit. Da riga di comando il bundle appare come un normale direttorio. Questa approccio non fu possibile per il Mac OS originale dato che il file system MFS non supportava i direttori e le cartelle. Mac OS X mantiene le API del gestore delle risorse classico come parte delle librerie Carbon per la retrocompatibilità. Comunque, le stesse risorse possono ora essere registrate in file di dati separati all'interno del file system dato che il gestore delle risorse ora nasconde questa implementazione dal codice utilizzatore.

Collegamenti esterni

(EN) Descrizione del formato delle resource fork, su developer.apple.com. URL consultato il 4 maggio 2019 (archiviato dall'url originale il 10 ottobre 2008).
(EN) Apple Developer Resource Library: Resource Manager Reference, su developer.apple.com. URL consultato il 4 maggio 2019 (archiviato dall'url originale il 25 aprile 2009).
(EN) Apple Developer Resource Library: Resource Management, Bundles, su developer.apple.com. URL consultato il 4 maggio 2019 (archiviato dall'url originale il 23 marzo 2009).
(EN) Apple Docs: Disable Resource Forks On Network Disks, su docs.info.apple.com. URL consultato il 22 agosto 2006 (archiviato dall'url originale il 19 aprile 2006).
(EN) osxutils^{[collegamento interrotto]} - comandi per Mac OS X che rispettano le resource fork
(EN) Storia della resource fork (TXT), su folklore.org (archiviato dall'url originale il 23 ottobre 2006).

Portale Apple: accedi alle voci di Wikipedia che trattano di Apple