Es gibt zwei grundlegende Möglichkeiten, um zu überprüfen, ob zwei Dateien identisch sind. Der erste besteht darin, zu überprüfen, ob ihre Pfade gleich sind . Dies hat keine falsch positiven, aber viele falsch negative Ergebnisse. Ein offensichtlicher Fall von falsch negativen Ergebnissen ist, wenn symbolische Verknüpfungen beteiligt sind. Sie können diesen Fall behandeln, indem Sie die symbolischen Links auflösen. Für vorhandene Verzeichnisse, in die Sie wechseln dürfen, ist dies möglich pwd -P.
absolute_path1="$(cd -- "$path1" && pwd -P; echo .)" &&
absolute_path2="$(cd -- "$path2" && pwd -P; echo .)" &&
[ "$absolute_path1" = "$absolute_path2" ]
Das Extra echo .kümmert sich um den seltenen Fall, dass eines der Ziele einen Dateinamen hat, der mit einer neuen Zeile endet: Wenn die neue Zeile das letzte Zeichen der Befehlsersetzung wäre, würde sie entfernt, sodass das Snippet fälschlicherweise meldet, dass dies foodasselbe ist wie foo.
Es gibt immer noch mögliche falsche Negative. Bei Verzeichnissen spielen feste Verknüpfungen keine Rolle, da die meisten Betriebssysteme und Dateisysteme das Verknüpfen von Verzeichnissen verbieten. Was passieren kann ist, dass dasselbe Verzeichnis irgendwie an verschiedenen Orten verfügbar gemacht wird, wie zum Beispiel:
Mounten des gleichen Remote-Dateisystems an zwei verschiedenen Orten, z
mount server:/some/where /mnt1
mount server:/some/where /mnt2
compare /mnt1 /mnt2
Ein Bind Mount
- Jedes stapelbare Dateisystem, dh eine Möglichkeit, ein Dateisystem auf eine andere Art und Weise darzustellen, wobei Sie die Ansicht des Verzeichnisses als ausreichend unverändert gegenüber dem Original betrachten, sodass es praktisch dasselbe Verzeichnis ist. Beispiel: Ein stapelbares Dateisystem, das Dateinamen konvertiert, und der Name des Verzeichnisses ist bei der Konvertierung unveränderlich.
In diesen Beispielen ist fraglich, ob die Verzeichnisse wirklich gleich sind. Dies zeigt die Grenze des Begriffs "gleiche Datei" in Randfällen.
Die zweite grundlegende Möglichkeit besteht darin , die vom Kernel bereitgestellte Identifikation zu überprüfen: Gerät und Inode . Der statSystemaufruf meldet zwei Attribute für jede Datei:
- die Gerätenummer (
st_dev), die traditionell eine Identifikation des Blockgeräts (Festplattenpartition) ist, das das Dateisystem enthält, auf dem sich die Datei befindet;
- die inode number (
st_ino), die traditionell eine eindeutige Nummer ist, die die Datei innerhalb desselben Dateisystems identifiziert.
Normalerweise sind zwei Dateien genau dann identisch, wenn sie die gleichen Geräte- und Inode-Nummern haben. Dash, ksh, bash, zsh und zumindest einige BusyBox-Builds (aber nicht einfache POSIX sh) haben einen -efOperator für das testeingebaute System, der Folgendes testet:
[ "$path1" -ef "$path2" ]
Dies behandelt Hardlinks und symbolische Links korrekt (symbolische Links werden befolgt, dh ein symbolischer Link zu einer Datei wird als derselbe wie die Zieldatei angesehen).
Diese Methode ist am einfachsten durchzuführen, wenn Ihre Shell (oder Ihr testDienstprogramm) dies unterstützt -ef. Beachten Sie jedoch, dass es falsch positive Ergebnisse gibt, da nicht alle Dateisysteme eindeutige Inode-Nummern melden. Bei Netzwerkdateisystemen sind Sie beispielsweise der Wahl der Inode-Nummern des Remote-Hosts ausgeliefert. Viele stapelbare Dateisysteme melden den zugrunde liegenden Inode, der nicht eindeutig ist, wenn der zugrunde liegende Verzeichnisbaum mehrere Dateisysteme umfasst.
Ein anderer Ansatz besteht darin , die beobachtbare Äquivalenz zu testen : Ändern Sie eines der Verzeichnisse und prüfen Sie, ob sich die Änderung im anderen widerspiegelt. Dieser Ansatz hat im Prinzip keine falschen Negative, erfordert jedoch die Berechtigung zum Ändern der Verzeichnisse und kann andere Teile des Systems stören, die diese Verzeichnisse verwenden. Es kann zu Fehlalarmen kommen, da die angezeigten Änderungen darauf hinweisen können, dass ein Daemon die Verzeichnisse sehr schnell synchronisiert.