Classiquement, dans un système de fichiers sans gestion de forks, un fichier ne comprend qu'une seule branche, celle des données proprement dites. Dans un système de fichiers prenant en charge les forks, un fichier peut être constitué de plusieurs branches (dont, généralement, celle des données). Autrement dit, tout fichier non vide est constitué d'au moins un fork, souvent de type par défaut, ainsi qu'un ou plusieurs autres forks associés, qui peuvent contenir soit des données primaires qui constituent le fond du fichier, soit tout simplement des métadonnées. À la différence des attributs étendus, une fonctionnalité similaire du système qui est généralement de taille fixe, un fork est de taille variable. La taille d'un fichier est la somme des tailles de chacune de ses branches.
Alternatives
Sur les systèmes de fichiers qui en sont dépourvus, les forks peuvent être simulés de plusieurs manières différentes. L'une des façons les plus courantes consiste à faire jouer le rôle de forks à des fichiers réguliers associés les uns aux autres au moyen d'un fichier particulier appelé fichier sidecar. Le défaut de cette solution est que le lien entre ces fichiers n'est pas conservé automatiquement par le système de fichiers, et dès lors il revient à l'application concernée de gérer convenablement ces fichiers. Une autre solution est de s'appuyer sur un fichier conteneur, qui stocke des données supplémentaires à l'intérieur d'un fichier spécialement formaté, ou un fichier d'archive, qui stocke plusieurs fichiers et les métadonnées associées dans un fichier unique (au sein d'une seule branche). Cela exige que les programmes de traiter le fichier conteneur ou un fichier d'archive, plutôt que de la gestion du système de fichiers fourches. Ces solutions nécessitent des travaux supplémentaires par les programmes utilisant les données, mais bénéficier de la portabilité pour les systèmes de fichiers qui ne prennent pas en charge les fourches.
Implémentations
Apple
Les forks sont intimement liés au système de fichier des Macintosh d'Apple, le Hierarchical File System (HFS)[1]. Le HFS et le MFS (le système de fichiers originel des Macintosh) autorisaient un objet fichier de compter plusieurs branches : une branche de données, une branche de ressources et d'autres branches nommées.
La branche de ressources est une branche spéciale destinée au stockage des données non compilées utilisées par l'interface graphique (GUI), telles que du texte localisé, les icônes d'une application ou de ses fichiers affichées par le Finder ou les menus et boîtes de dialogue associées à une application[2]. Du fait de la flexibilité de la fonctionnalité, les forks ont connu d'importants usages, comme diviser dans un traitement de texte un document en deux parties, le contenu et la présentation, chaque partie étant stockées dans une ressource distincte. De même, le code exécutable des logiciels était également stockée dans une ressource, et par conséquent les applications étaient constituées uniquement d'une branche de ressources.
L'une des caractéristiques les plus méconnues de HFS+'s est la possibilité d'avoir un nombre arbitraire de « branches nommées », en plus des traditionnelles branches de données et de ressources. Cette fonctionnalité restée largement inutilisée, car Apple n'a jamais inclus sa prise en charge sous Mac OS 8.1 à 10.3.9. À partir de 10.4, une prise en charge partielle a été mise en place pour implémenter les attributs en ligne étendus.
Ce n'est qu'à l'arrivée de Mac OS X v10.4 que les utilitaires standards Unix inclus dans le système (par exemple l'utilitaire d'archivage de fichiers tar) ont été mis à jour pour gérer convenablement toutes les branches d'un fichier. Auparavant, les utilisateurs risquaient des pertes de données[3].
Transmissions
La transmission de fichiers entre utilisateur de MacOS via des canaux non spécifiques (disques externes Windows, email, ...) nécessitait l'utilisation d'encodages supportant les fork comme BinHex(en) (extensions .hqx)
Novell
À partir de 1985, NetWare File System (NWFS), et son successeur, Novell Storage Services (NSS), ont été conçus dès l'origine pour prendre en charge différentes méthodes de stockage des métadonnées d'un fichier. Certaines métadonnées sont gérées par les Novell Directory Services (NDS), d'autres sont stockées dans la hiérarchie de répertoires sur le disque, et d'autres encore sont stockées, comme le précise Novell, dans de « multiples flux de données » inclus dans le fichier lui-même. Ces flux de données supplémentaires permettent aux clients Macintosh de se connecter aux serveurs NetWare et d'utiliser leurs services.
Microsoft
Le système de fichiers NTFS, introduit avec Windows NT 3.1, prend en charge les forks sous le nom d'Alternate Data Streams (ADS, en français : flux de données alternatifs)[4]. ReFS, le nouveau système de fichiers introduit avec Windows Server 2012, ne prenait pas en charge à l'origine les ADS[5],[6],[7], mais ils ont été intégrés dans Windows 8.1 64-bit et Windows Server 2012 R2[8].
Windows 2000 utilise les ADS pour stocker les miniatures d'images et des informations complémentaires (comme le titre et l'auteur de l'image) sans toucher au données principales des fichiers[9],[10]. Microsoft a découvert l'existence de risques de pertes de données, comme, par exemple, lors du déplacement de fichiers contenant des ADS d'un volume NTFS sous Windows 2000 vers un volume FAT sous Windows XP ; sous ce système, les métadonnées sont intégrées au flux principal chaque fois que le format de fichier le permet. Devant la fragilité des ADS quant aux données à conserver, Microsoft a totalement abandonné cette méthode d'ajout d'informations avec Windows Vista[11]. Les ADS continuent cependant à être utilisés pour marquer les fichiers téléchargés depuis le NET. En effet le Service Pack 2 pour Windows XP a introduit l'Attachment Execution Service qui stocke des détails sur l'origine de fichiers téléchargés dans un flux nommé "Zone.Identifier", dans le but de protéger les utilisateurs des fichiers téléchargés qui peuvent présenter un risque[12]. Internet Explorer et Windows 8 remplissent cette fonction par le biais de SmartScreen[13]. Internet Explorer utilise également des flux pour stocker les Favicons des Marque-pages.
Sun
La gestion des forks est implémentée dans Solaris à partir de la version 9, sous le nom d'attributs étendus (qui diffèrent des attributs étendus classiques). La taille maximale d'un attribut étendu de type Solaris est la même que la taille maximale d'un fichier, et il est lu et écrit de la même manière qu'un fichier. En interne, les attributs étendus sont en fait stockés et accessibles comme des fichiers normaux, de sorte que leurs propriétés et les autorisations peuvent être différents de ceux du fichier parent. Leurs noms ne peuvent pas contenir de caractères "/".
Les attributs étendus dans la version 4 de Network File System sont similaires à ceux de Solaris.
Risques de sécurité et de perte de données
Les applications tournant sur un système d'exploitation dont le système de fichiers prend en charge les forks, doivent être adaptées pour les gérer, sinon des risques de sécurité ou des pertes de données peuvent survenir. La source principale de problèmes se situe dans les logiciels existants qui n'ont pas été adaptés, via des interfaces spéciales, pour accéder à des données avec forks.
L'utilisateur ne verra que la principale branche de données, et il ne sera pas prévenu de l'existence de branches de données supplémentaires, et la taille de fichier rapportée par le système sera fausse.
Des virus informatiques (notamment sur Windows) peuvent s'installer à l'intérieur d'un fork et ne jamais être détecté si l'antivirus ne prend pas en charge les forks.
Les données peuvent être perdues lors de l'envoi de fichiers via un canal ne prenant pas en compte les fork, tels que e-mail, les systèmes de fichiers sans support de fork, ou même lors de la copie de fichiers entre les systèmes de fichiers avec fork si le programme qui a fait la copie ne les prend pas en charge ou lors de la compression de fichiers avec un logiciel qui ne prend pas en charge les fork.
