Comment savoir quel fichier est original si un lien physique est créé

34

Par exemple, j'ai un fichier myold_file. Ensuite, je lncrée un lien en tant que mylink:

ln myold_file mylink

Ensuite, même en utilisant ls -a, je ne peux pas dire lequel est l'ancien.

Y a-t-il un moyen de le savoir?

filesystems hard-link

— BufBills
source

2

Contre-question: Si vous le faites ls > a; ln a b; rm a; ln b c, lequel est "plus original" que l'autre? aest parti, il vous reste bet c...

— glglgl

2

Qu'essayez-vous de réaliser? Qu'essayez-vous de réaliser? Il n'y a pas d '"original" en tant que tel. Un fichier est un inode contenant des métadonnées et une collection de blocs contenant des données. Un répertoire peut contenir un lien vers le fichier. Ce lien contient le nom du fichier et le numéro d'inode. Vous pouvez créer un nombre illimité de liens vers un fichier. Les fichiers ne peuvent jamais avoir moins d'un lien.

— Johan

Pour une explication détaillée de la réponse acceptée à cette question: Voir la réponse acceptée à cette question .

— Utku

93

Vous ne pouvez pas, car ils sont littéralement le même fichier, accessible uniquement par des chemins différents. Le premier n'a pas de statut particulier.

— Jenny D
source

4

C'est clairement la bonne réponse: la question du PO repose sur un malentendu.

— Daniel Earwicker

8

@Adnan En fait, non: les deux liens durs sont le même fichier. Ce sont des entrées de répertoire différentes. La terminologie de Jenny D est correcte.

— Gilles 'SO- arrête d'être méchant'

1

@ Gilles je ne vois pas comment cela peut être correct. Deux liens durs ne sont pas deux fichiers ; les liens durs ne sont pas des fichiers. Ils soulignent , par conséquent un lien , dans le même fichier (qui est l'emplacement physique sur le disque). Dire que "deux liens durs sont littéralement le même fichier" est faux.

— Adi

1

@ JennyD Et c'est à peu près la seule façon dont j'ai entendu parler de "lien dur"; un pointeur de système de fichiers vers un inode. Eh bien, je suppose que nous avons tous tort et raison. Je vais cesser de discuter, car c'est inutile. Votre réponse me semble correcte, vous avez un +1 de moi et je vais en rester là.

— Adi

5

Dire qu'un lien physique "est" un fichier compare des choses de différentes catégories, ce qui est techniquement incorrect. Mais étant donné que nous disons généralement, " .bashrcest un fichier contenant ...", lorsque nous entendons, "le chemin relatif .bashrcfait référence à un fichier contenant ...", il s'agit d'un mélange courant de catégories et nous devons comprendre que chaque fois que l'on fait référence à un chemin ou une entrée de répertoire "étant" un fichier, nous voulons dire le fichier auquel il fait référence. Avec cette compréhension, deux liens durs peuvent "être" le même fichier. Rejetant cette convention en faveur du langage formel, ils ne peuvent pas. Les deux positions ont leur place :-)

— Steve Jessop

16

Il n'y a pas de moyen direct et propre (fiable) de le faire. Mais dans des circonstances appropriées, cela peut être possible (ou du moins probable). Le problème est qu'il y a deux liens durs mais un seul fichier. Les temps de modification, de modification et (éventuellement) de création ne sont stockés que pour les fichiers (inodes), mais pas pour les entrées de répertoire (les liens physiques). Ainsi, les informations que vous souhaitez ne peuvent être extraites que des effets secondaires qui peuvent facilement être détruits par des opérations qui ne sont pas liées au fichier. Et vous ne pouvez même pas voir s'il a été détruit. Vous ne pouvez le savoir à partir des circonstances opérationnelles que si vous en êtes précisément conscient.

La création d'un lien dur est une opération d'écriture dans le répertoire qui contient le lien. Ainsi, il met à jour le répertoire mtime. Donc si

les liens sont dans des répertoires différents
et vous savez qu'aucun de ces répertoires n'a été modifié (fichier ajouté, supprimé, renommé ou changement de métadonnées de fichier) après la création du deuxième lien physique, vous pouvez simplement comparer le mtimes des répertoires.

Cas particulier: Si l'un des répertoires comporte un mtimeprécédant le fichier (l'inode) mtimeet que vous pouvez être raisonnablement sûr que le fichier n'a pas été écrit après un court instant après sa création, le lien de ce répertoire est le plus ancien.

Si les liens se trouvent dans le même répertoire (ce qui semble être le cas dans votre question), la situation empire. Ensuite, vous pouvez utiliser

ls -lU

afin d’obtenir une impression de l’ordre dans lequel les entrées ont été créées. Cet ordre n'est pas nécessairement correct car les entrées peuvent être supprimées, de sorte que de nouvelles entrées sont créées au milieu de la liste des répertoires. Et comme Gilles l'a souligné, cela ne fonctionne pas du tout avec les systèmes de fichiers les plus récents.

— Hauke Laging
source

2

Aucune mention de selinux, de pistes d'audit ou d'espionnage dans le journal du système de fichiers ??? smirk Sans piste d'audit, il n'y a aucun moyen de savoir - toute autre chose est une supposition

— Ricky Beam

1

@ mikeserv Si vous voulez enseigner aux autres de cette façon, vous devez au moins apprendre à citer correctement. Il ne dit pas "quel fichier" dans la question. Et même si cela se produisait, il ne s'agirait alors que d'un problème de formulation, et jeter un peu de réflexion à la compréhension de la question permettrait de mieux comprendre de quoi il s'agit.

— Hauke Laging

4

Le truc répertoire mtime fonctionnera si les circonstances le permettent (ce qui est rare). Cependant, de la façon dont vous le présentez, vous arriverez parfois à la conclusion opposée. Le répertoire mtime n'est utile que s'il est égal à ctime du fichier. Mais l' ls -lUastuce ne fonctionnera pas sur les systèmes de fichiers modernes (ext4, btrfs, zfs), car les entrées ne s'affichent pas du tout dans l'ordre de création.

— Gilles 'SO- arrête d'être méchant'

2

@mikeserv - la question du PO repose sur un malentendu. Si elles existaient rm myold_filealors mylink, elles existeraient toujours et fonctionneraient parfaitement, car il s'agit d'une entrée tout aussi bonne faisant référence au même inode sous-jacent. Ce n'est que lorsque les deux ont été supprimés que le système peut supprimer l'inode. Une fois que la liaison matérielle a été utilisée pour créer deux entrées de système de fichiers faisant référence au même fichier, elles sont équivalentes. (Notez que "fichier" signifie ici "un inode qui contient les données d'un fichier, par opposition à un répertoire.) Voir: en.wikipedia.org/wiki/Inode

— Daniel Earwicker

1

-1 parce que, bien que les informations sur la façon dont le répertoire change dans certains systèmes de fichiers lors de la mise à jour des tables, cette réponse n'éclaircit pas la compréhension erronée présente dans la question que "fichier d'origine" n'est pas une propriété dans le cas de liens multiples multiples à un seul inode. En ce sens, même si son contenu est anecdotique, ce n'est pas ce que la plupart des gens qui abordent cette question devraient en apprendre davantage sur le concept fondamental des liens fixes. Ce problème n’est pas l’absence d’une "méthode propre et directe pour le faire", c’est qu’il n’existe pas de "cela" en premier lieu.

— Caleb

10

Si vous vous fiez à la dernière heure de modification des répertoires et que vous ne savez pas comment et quand ces répertoires sont modifiés, compter sur mtime vous conduira à vous tromper un certain pourcentage du temps. Le problème ici est que le fichier est représenté dans le système de fichiers par un inode, pas par une entrée de répertoire. L'entrée de répertoire (nom de fichier) pointe vers l'inode, pas le fichier.

Je pense que je me demanderais peut-être pourquoi j'ai besoin de savoir quelle entrée de répertoire est la plus ancienne et comment éviter de devoir le savoir.

— Melinda
source

8

Je pense que cette question est (tout à fait raisonnablement) erronée quant à ce qu'est réellement un lien solide. Je pense cependant que la réponse directe la plus correcte est «ils sont tous les deux» .

Les systèmes de fichiers Unix stockent normalement le contenu actuel des fichiers et les données dans des i-nœuds, ceux-ci n’ayant aucun chemin, ceux-ci ont alors une relation plusieurs à un avec ces i-nœuds. Prenons comme analogie une personne qui porte deux noms, Bob et Joe. On ne peut pas dire que Bob est plus âgé que Joe ou vice-versa, ce ne sont que des noms pour la même personne.

Si vous souhaitez conserver le concept de fichier «original» et un nouveau fichier, vous recherchez probablement un lien symbolique. Il s’agit plutôt d’un alias, il s’agit simplement d’une instruction donnée au système d’exploitation de étaient à un autre sans changer la structure de fichier en dessous. (Vous pouvez les créer avec "ln -s file link".

— Vality
source

Vous savez, Bob / Joe peut être très sensible à son âge ... La comparaison de liens physiques / matériels est une bonne comparaison - en particulier si vous considérez qu'un lien physique se voit simplement ajouter une entrée dans un fichier de répertoire - un fichier déjà existant. inode - mais un lien symbolique est un fichier à part entière, et se voit donc attribuer son propre inode. Néanmoins, dans les deux cas, l’heure de modification n’est pertinente que pour le fichier lié, car les seules modifications pouvant être apportées à un lien important ne seraient que la création / la suppression.

— mikeserv

2

Le noeud de la réponse donnée par plusieurs autres personnes ci-dessus est que le nom de chaque fichier est un lien physique vers un fichier. Il n'y a pas de véritable original, mais peut-être même un premier.

Pensez à un répertoire comme une table qui répertorie les noms de fichiers et les numéros d'inode.

Chaque lien physique, y compris le premier, est une entrée dans un répertoire qui attribue un "nom de fichier" au numéro d'inode, afin que vous puissiez accéder au fichier par ce nom.

Le fichier est un ensemble de blocs sur disque, gérés et suivis par des métadonnées stockées dans un inode. Un fichier a un numéro d'inode.

L'accès aux données d'un fichier via le nom de fichier est un processus en trois étapes: Le nom du fichier est recherché dans le répertoire pour obtenir le numéro d'inode. Il est ensuite fait référence à l'inode pour trouver le ou les blocs de disque pertinents contenant les données. Enfin, ces blocs sont lus / écrits.

En résumé, voici ce qu’il faut retenir: Il n’ya absolument aucune différence entre l’accès au contenu du fichier à l’aide du premier ("original") ou de tout lien créé ultérieurement.

— Johan
source