cp Kopierreihenfolge

[fischig]

Nach welchen Kriterien bestimmt cp eigentlich, in welcher Reihenfolge die Dateien eines Verzeichnisses kopiert werden? Die alphabetische Reihenfolge der Dateinamen ist' s offensichtlich nicht.

[Meillo]

Nach welchen Kriterien bestimmt cp eigentlich, in welcher Reihenfolge die Dateien eines Verzeichnisses kopiert werden? Die alphabetische Reihenfolge der Dateinamen ist' s offensichtlich nicht.

Meinst du `cp -r'? Denn wenn du Dateien explizit als Argumente angibst, dann werden diese sicherlich in der angegebenen Reihenfolge kopiert.

Bei rekursivem Kopieren eines ganzen Verzeichnisses werden die Inhalte vermutlich in der Reihenfolge kopiert, wie sie gelesen werden, was wohl nach der (eher zufaelligen) Reihenfolge der Verzeichniseintraege der Fall sein wird. (Siehe dazu `ls -U'.)

[fischig]

Meinst du `cp -r'?

Ja.

Bei rekursivem Kopieren eines ganzen Verzeichnisses werden die Inhalte vermutlich in der Reihenfolge kopiert, wie sie gelesen werden, was wohl nach der (eher zufaelligen) Reihenfolge der Verzeichniseintraege der Fall sein wird.

Hmmm, Zufall gibt's nicht - denk ich mal. „Reihenfolge der Verzeichniseinträge“: Da stelle ich mir dann sowas wie Erstellungsdatum vor. könnte Sinn machen. Ist auch nicht so wichtig. Ich beobachte gerade das Kopieren der Videos in einem Verzeichnis. Eigentlich sieht das ziemlich alphabetisch aus, aber dann kommt plötzlich der „dressmaker“ hinter dem „untertan“! rätsel, rätsel.

[MSfree]

Die Reihenfolge dürfte die sein, die du auch mit

Code: Alles auswählen

ls -U

bekommst. Im Grunde ist das die Reihgenfolge, mit der die Dateien auf dem Datenträger angelegt worden sind, also zufällig aber reproduzierbar.

[Meillo]

Im Grunde ist das die Reihgenfolge, mit der die Dateien auf dem Datenträger angelegt worden sind, also zufällig aber reproduzierbar.

Dem ``im Grunde'' stimme ich zu.

Die Frage, ob es reproduzierbar ist, finde ich spannend. Definiert ist das fuer unixoide Dateisysteme sicherlich nicht. Gerade beim Loeschen von Verzeichniseintraegen koennte ich mir vorstellen, dass sich da verschiedene Dateisysteme unterschiedlich verhalten, wodurch das Verhalten von einem Dateisystem nicht unbedingt auf ein anderes uebertragen werden kann. Auf dem gleichen Dateisystem wuerde ich mich auf die Reihenfolge der Verzeichniseintraege nur in der gleichen Weise verlassen wie auf die Reihenfolge von Eintraegen in Hashes: besser davon ausgehen, dass sie zufaellig ist. (Darum mischen uebrigens die Entwickler von Go Hashes bei jedem Lesen neu durch: man soll gar nicht auf die Idee kommen, irgendetwas in die Reihenfolge hineinzuinterpretieren. )

Aber nun interessiert mich doch, wie es einzelne Dateisysteme nun ganz konkret machen ...

[fischig]

Na, da hab' ich ja was losgetreten.

[debra]

Ich habe das jetzt nur überflogen. Aber wenn ich das richtig sehe nehmen die gnutools (Also das normale cp unter debian. Es gibt alternativen in den Quellen ) cp.c das copy.c nutzt. Das included savedir.h

Code: Alles auswählen

enum savedir_option
  {
    SAVEDIR_SORT_NONE,
    SAVEDIR_SORT_NAME,
#if D_INO_IN_DIRENT
    SAVEDIR_SORT_INODE,
    SAVEDIR_SORT_FASTREAD = SAVEDIR_SORT_INODE
#else
    SAVEDIR_SORT_FASTREAD = SAVEDIR_SORT_NONE
#endif
  };

=> Unter Linux/BSD/Hurd wird in der Reihenfolge der inode-Nummern kopiert. Die dürften weitestgehend nach Zeitpunkt des Erstellens der Datei auf dem Dateisystem vergeben werden. (Nicht das Erstelldatum der Datei selbst das deutlich älter sein kann, weil sie von wo anders kopiert/verschoben wurde.)
Hat den Vorteil, das die Reihenfolge selbst nach defragmentieren/verschieben etc. relativ statisch bleibt. – Außer auf Dateisystemen, wie FAT, die keine inodes haben und so jedes mal andere beim mounten vergeben werden.
Das unterscheidet sich von ls -U das die Dateien in der Reihenfolge liefert wie sie auf der Platte stehen, was bei ReiserFS der alphabetischen Reihenfolge entspricht und bei ext kompliziert ist*.
Selbstverständlich werden alle auf ähnliche Reihenfolgen hinauslaufen, wenn man z.B mit wget -r irgend was runter lädt und Downloadreihenfolge alphabetisch ist und Schreibreihenfolge und Erstellreihenfolge entspricht.

* https://www.kernel.org/doc/html/latest/ ... ctory.html

Edit: Klarstellung: Mit reihenfolge der Inodes ist die numerische Reihenfolge gemeint. Nicht die Platzierung.

[uname]

Vielleicht habe ich das Thema falsch verstanden. Aber geht es nicht um das Kopieren von Dateien nur aus einem Verzeichnis.

Stellen wir uns vor unser Verzeichnis enthält viele Dateien und hierbei nur drei Textdateien. Enthalten ist auch ein Zielverzeichnis

Code: Alles auswählen

1.txt
2.txt
3.txt
...
Zielverzeichnis

Wenn man nun kopiert

Code: Alles auswählen

cp *.txt Zielverzeichnis

expandiert es die Shell, wie man es auch testen kann:

Code: Alles auswählen

echo cp *.txt Zielverzeichnis
cp 1.txt 2.txt 3.txt Zielverzeichnis

Simulieren könnte man es auch mit einem normalen echo:

Code: Alles auswählen

echo *.txt
1.txt 2.txt 3.txt

/bin/echo gehört zu coreutils. Vielleicht mag jemand den Quellcode mal analysieren. Dann könnte man vielleicht für dieses Beispiel die Reihenfolge ermitteln.

[fischig]

@uname
Ich hatte das Verzeichnis mitkopiert. Und die darin befindlichen Dateinamen haben keinerlei gemeinsame Endungen.
Ohne ins Detail gehen zu wollen (und zu können! ): Darf ich dich so extrapolieren: Gesetzt ich befände mit im Verzeichnis, dessen Dateien ich kopieren will, dann benutzte cp mit diesem Kommando
cp -rv * zielverzeichnis
als Reihenfolge die alphabetische Reihenfolge der Dateinamen beim Kopieren?
Die Kopierreihenfolge Ist ja im Grunde aus Nutzersicht uninteressant, solange alle Dateien kopiert werden. und eine Reihenfolge lässt sich beim Kopiervorgang ja eh nur erkennen, wenn ein „v“ im Parameter steckt.

[MSfree]

Die Frage, ob es reproduzierbar ist, finde ich spannend.

Repeoduziwerbar ist das in dem Sinne, daß ls -U die Dateien immer in derselben Reihenfolge liefert, es sei denn, man löscht eine Datei oder fügt eine neue Datei im aktuellen Verzeichnis hinzu.

In der Verzeichnisstruktur der im Dateisystem abgelegten Dateireihenfolge ändert sich ja nur etwas, wenn Dateien weggenommen oder hinzugefügt werden. Die Dateinamen sind in dieser Struktur nicht sortiert abgelegt sondern in der Reihenfolge, wie sie angelegt wurden, und das ist eben mehr oder weniger zufällig aber theoretisch reproduzierbar. Programme wie ls lesen die Dateinamensliste ein und geben sie sortiert aus, die Standardsortierung ist alphabetisch, kann aber über Optionen auch nach Datum/Zeit oder mit -U eben auch unsortiert erfolgen.

Aber nun interessiert mich doch, wie es einzelne Dateisysteme nun ganz konkret machen ...

Naja, irgendwo im Dateisystem ist ja die Tabelle gespeichert, die die üblichen Dateiattribute wie Name, diverse Zeitstempel und Zugriffsrechte beinhaltet. Diese Tabelle wird eben vom ersten Element beginnend gefüllt. Löscht man eine Datei, entsteht ein "Loch" in der Tabelle, die mit dem Anlegen einer neuen Datei gefüllt wird. So wird zumindest bei "einfacheren" Dateisystemen wie FAT vorgegangen. Bei fortgeschritteren Dateisystemen gibt es keine Tabelle sondern verkettete Listen oder Binärbäume. Die zufällige Reihenfolge der Dateinamen ist aber in jedem Dateisystem inherent.

[Meillo]

Die Frage, ob es reproduzierbar ist, finde ich spannend.

Repeoduziwerbar ist das in dem Sinne, daß ls -U die Dateien immer in derselben Reihenfolge liefert, es sei denn, man löscht eine Datei oder fügt eine neue Datei im aktuellen Verzeichnis hinzu.

Ja, da wird man vermutlich bei allen derzeit verfuegbaren Unix-Dateisystemen immer die gleiche Reihenfolge zurueckbekommen. Ich dachte, du meinst vielleicht, dass reproduzierbar ist, was passiert, wenn man Dateien hinzufuegt und wegnimmt usw. Da waere ich naemlich vorsichtiger.

Aber nun interessiert mich doch, wie es einzelne Dateisysteme nun ganz konkret machen ...

Naja, irgendwo im Dateisystem ist ja die Tabelle gespeichert, die die üblichen Dateiattribute wie Name, diverse Zeitstempel und Zugriffsrechte beinhaltet. Diese Tabelle wird eben vom ersten Element beginnend gefüllt. Löscht man eine Datei, entsteht ein "Loch" in der Tabelle, die mit dem Anlegen einer neuen Datei gefüllt wird. So wird zumindest bei "einfacheren" Dateisystemen wie FAT vorgegangen. Bei fortgeschritteren Dateisystemen gibt es keine Tabelle sondern verkettete Listen oder Binärbäume.

Wie genau das intern gemacht wird, ist eben implementationsabhaengig. Tabellen, Listen und Suchbaeume haben ein definiertes Verhalten, das jedes Mal gleich sein wird, wenn man die gleichen Aktionen ausfuehrt. Ein Dateisystem koennte aber auch komplexere Verfahren mit globalen Caches und Deduplizierung und Historisierung und was weiss ich noch alles einsetzen, wodurch sich auch Vorgaenge an anderen Stellen im Dateisystem darauf auswirken, wie genau die Verzeichniseintraege in unserem Verzeichnis angelegt werden ... oder es nutzt im Hintergrund eine Datenbank dafuer, wodurch wir gar keinen Einfluss mehr darauf haben, was intern passiert. Es koennte sogar beim Lesen eines unveraenderten Verzeichnisses jedes Mal eine andere Reihenfolge zurueckkommen. Ich will nicht sagen, dass es normalerweise so waere, aber ein Unix-Dateisystem koennte es so machen. Darum sollten wir besser keinerlei Erwartungen an die Reihenfolge von unsortierten Verzeichniseintraegen haben.


@debra: Danke fuer den Link zu den ext-Dateisystemen. Das muss ich mir noch genauer anschauen.

[Meillo]

Vielleicht habe ich das Thema falsch verstanden. Aber geht es nicht um das Kopieren von Dateien nur aus einem Verzeichnis.

Ja, sobald du die Argumente auf der Kommandozeile angibst, sorgt die Shell fuer eine Sortierung.

Wenn man nun kopiert

Code: Alles auswählen

cp *.txt Zielverzeichnis

expandiert es die Shell, wie man es auch testen kann:

Code: Alles auswählen

echo cp *.txt Zielverzeichnis
cp 1.txt 2.txt 3.txt Zielverzeichnis

Simulieren könnte man es auch mit einem normalen echo:

Code: Alles auswählen

echo *.txt
1.txt 2.txt 3.txt

/bin/echo gehört zu coreutils. Vielleicht mag jemand den Quellcode mal analysieren. Dann könnte man vielleicht für dieses Beispiel die Reihenfolge ermitteln.

Die Sortierung in diesem Fall wird schon von der Shell gemacht, wenn sie den Stern expandiert. echo(1) sortiert nichts.

cp(1) sortiert auch nichts. Entweder es arbeitet die Argumente in der Reihenfolge ihrer Parameter ab oder, beim rekursiven Kopieren, die Eintraege in den Verzeichnissen (vermutlich) in der Reihenfolge wie es sie liest (siehe readdir(3)). Dazu sollten wir nochmal einen Blick in den Code werfen. (Ich habe gerade leider nicht die Zeit dazu.)

Die Ebene darunter betrifft dann die Frage, wie das Dateisystem die Eintraege in einem Verzeichnis organisiert. Das kann bei jedem Dateisystem anders sein. Auch hier waere ein Blick in konkreten Code interessant ... (debra hat schon eine Beschreibung zu ext gepostet.)

Ich finde diese Fragen sehr interessant und wuerde die gerne noch weiter vertiefen. Hoffentlich finde ich bald Zeit dazu.

[debra]

cp(1) sortiert auch nichts. Entweder es arbeitet die Argumente in der Reihenfolge ihrer Parameter ab oder, beim rekursiven Kopieren, die Eintraege in den Verzeichnissen (vermutlich) in der Reihenfolge wie es sie liest (siehe readdir(3)).

Wie gesagt: Die coreutils haben explizit einen Sortieralgorithmus nach inode-nummer drin. (qsort_r) Für mich sieht es so aus, als ob der unter Linux auch genutzt wird. Es ist also explizit nicht die Reihenfolge von readdir, die ls nutzt:
"Sortier-Code" dafür -U in ls:

Code: Alles auswählen

if (sort_type == sort_none)
    return;