Interface native avec le système de fichier: pourquoi des "hard link"

Bonjour,
En essayant d’utiliser un système de fichier externe avec le composant natif, j’ai rencontré des échecs car ce système n’autorisait pas les “hard link”, hors le framework utilise comme témoin de “lock” des fichiers un “hard link” sur le fichier “document”. A priori un fichier vide aurait fait l’affaire pour jouer le rôle de témoin de verrouillage, mais ce lien hard laisse supposer qu’il y a un autre rôle, peut-être transactionnel …

Est-ce que quelqu’un sait pourquoi on utilise un hard link ?

Bonjour Laurent,

J’ai fait une recherche rapide sur les tickets de développement de la fonctionnalité en question. Il apparaît que c’est un choix délibéré du développeur qui voulait s’assurer de ne pas avoir de conflit à gérer lors du lock en utilisant une “fonction atomique” (Mauvaise traduction du suivi de ce développement qui s’est fait en anglais).

Ajouté le 10/12/2012 14:32

In PHP the only atomic command is link. However, using link can’t be done between the filesystems since it is a hard link that is created, and if user’s home and root are mounted on different filesystems, the link command will fail.

For this reason there should be a file located on the same filesystem as the directory root of the files to be stored. TO make sure this problem is avoided the file with extension .lock is a link to the file containing the raw data.

Suppose, for example, that we have the following directory structure:
02
02/0234
02/0234/02343e4c1881ba5b4f8b60e351bdbfe4
02/0234/02343e4c1881ba5b4f8b60e351bdbfe4.info
02/0234/02343e4c1881ba5b4f8b60e351bdbfe4.lock
Then the file 02/0234/02343e4c1881ba5b4f8b60e351bdbfe4.lock is a hard link to 02/0234/02343e4c1881ba5b4f8b60e351bdbfe4

Florent.

Merci pour l’enquête :slight_smile: