find: Änderung in Debian 12 ?

[mrserious]

Hallo,

habe vor einer Weile mal ein kleines Skript geschrieben, das mir die Dateien seit einem bestimmten Datum aus einem Verzeichnis heraus kopiert:

Code: Alles auswählen

find /dir -type f -newermt 2023-01-01 -exec cp --parents -at /zielverzeichnis {} +

Seit des Updates auf Debian 12 erhalte ich beim Ausführen des Skripts nun Meldungen, die ich noch nicht ganz zuordnen kann.
Könnt ihr mich aufklären?

Code: Alles auswählen

cp: „dir/irgend/ein/Ordner“: Datei oder Verzeichnis nicht gefunden

[chrbr]

Kann es sein, dass das Zielverzeichnis seit dem Upgrade nicht mehr existiert?

[Meillo]

Wieso nennt die Fehlermeldung denn eigentlich einen *Ordner*, wenn der find-Aufruf nur Dateien auswaehlt?

Was gibt der find-Befehl aus, wenn du `-exec' und den Rest der weglaesst? (Dann sollten die gefundenen Dateien aufgelistet werden.) Passen die Pfade da?

Wo ist der Slash vor `dir' hingekommen? Das macht fuer mich keinen Sinn. Ist das wirklich das ganze Script, oder gibt's da noch irgendwelche Variablen oder so?

[mrserious]

Guten Morgen,

entschuldigt, in dem Versuch, es für euch leichter zu machen habe ich tatsächlich die Variablen weggelassen

Leider funktioniert's aber auch nicht, wenn ich von Hand alles auf der Shell eingebe.
Wichtig: Die Daten werden aber trotzdem korrekt in das Zielverzeichnis kopiert!
Trotzdem hier einmal das Skript inkl. Variablen:

Code: Alles auswählen

zielverzeichnis="/ein/anderer/Ordner"
datum="2023-06-16"

mkdir $zielverzeichnis/subdir

find /dir -type f -newermt $datum -exec cp --parents -at $zielverzeichnis/subdir {} +

[Meillo]

Generell sollte man alle Variablenexpansionen double-quoten. Hier sollte es zwar keinen Unterschied machen, aber sicher ist sicher, und bevor man tiefer in die Fehlersuche einsteigt, sichert man besser die Grundlagen.

Mich irritiert immer noch die Fehlermeldung, dass dort der Slash am Anfang fehlt. Bist du dir sicher, dass die korrekt so ist. Du hast ja alle Pfade anonymisiert. Nicht dass du aus Versehen den Slash entfernt hast.

Wenn du sagst, dass etwas kopiert wird, dann wende das Script doch mal ohne die Datumsbedingung an, dann sollten *alle* Dateien darin kopiert werden. Dann kannst du den Ausgangs- und Zielordner mit `diff -rq' vergleichen, ob auch wirklich keine fehlt.

Zum Debuggen kannst du mit `set -x' die Ausgabe der ausgefuehrten Befehle einschalten oder einfach zwischen `-exec' und `cp' ein `echo' setzen, dann wird der Kopierbefehl nicht ausgefuehrt, sondern im Terminal ausgegeben. Vielleicht faellt da irgendwas auf.

Du solltest diese Dinge schrittweise durchgehen, um deine Annahmen zu pruefen.

[MSfree]

Code: Alles auswählen

zielverzeichnis="/ein/anderer/Ordner"
mkdir $zielverzeichnis/subdir

Voraussetzung dafür, daß /ein/anderer/Ordner/subdir mit mkdir angelegt werden kann, ist, daß /ein/anderer/Ordner bereits existieren. Das war aber schon immer so.

Wenn du die übergeordneten Verzeichnisse mitanlegen lassen willst, mußt du

Code: Alles auswählen

mkdir -p $zielverzeichnis/subdir

verwenden. Das Stellt sicher, daß zuerst /ein erzeugt wird, sollte es nicht exisieren, dann /ein/anderer und schließllich /ein/anderer/Ordner, bevor versucht wird /ein/anderer/Ordner/subdir anzulegen.

[Meillo]

@MSfree: Das ist ein guter Hinweis, der das Script robuster macht. Fuer die Fehlermeldung scheint mir das aber nicht verantwortlich zu sein. Die bezieht sich doch auf die Quelldatei und nicht auf das Zielverzeichnis. Ich vermute also, dass das Zielverzeichnis korrekt angelegt worden ist, denn sonst haette `mkdir' schon einen Fehler geworfen.

[MSfree]

Die bezieht sich doch auf die Quelldatei und nicht auf das Zielverzeichnis.

Was macht dich da so sicher?

Die Meldung aus dem OP:

Code: Alles auswählen

cp: „dir/irgend/ein/Ordner“: Datei oder Verzeichnis nicht gefunden

könnte auch bedeuten, daß das Ziel nicht gedunden wurde, was dann an dem mkdir liegen könnte.

[tobo]

Die bezieht sich doch auf die Quelldatei und nicht auf das Zielverzeichnis.

Was macht dich da so sicher?

Dass die Daten korrekt ins Zielverzeichnis übertragen wurden?

Es geht einfach nichts über reguläre Ausgaben der Konsole...

[Meillo]

Die bezieht sich doch auf die Quelldatei und nicht auf das Zielverzeichnis.

Was macht dich da so sicher?

Die Meldung aus dem OP:

Code: Alles auswählen

cp: „dir/irgend/ein/Ordner“: Datei oder Verzeichnis nicht gefunden

könnte auch bedeuten, daß das Ziel nicht gedunden wurde, was dann an dem mkdir liegen könnte.

Dann wuerde `mkdir' schon die Fehlermeldung liefern. Wenn `mkdir' funktioniert, dann sollte `cp' auch funktionieren. Mir faellt kein Fall ein, bei dem ersteres geht aber zweiteres wegen dem Zielverzeichnis nicht.

Zudem muesste dann in der Fehlermeldung von `cp' der Zielpfad (/ein/anderer/Ordner) stehen und nicht der Quellpfad (dir/irgend/ein/Ordner).

[mrserious]

Also ich habe die Pfade gerade noch einmal geprüft: Sie sind definitiv korrekt.
Danke für den Hinweis zu "mkdir -p" ! Auch hier ist es aber so: Die Pfade haben sich durch das Neuinstallieren des Systems nicht geändert, da sie nicht auf der root-Partition liegen.
Es sind also nach wie vor alle Verzeichnisse und Unterverzeichnisse korrekt vorhanden.

Falls ich das missverständlich formuliert habe:
Effektiv funktioniert auch alles! Sowohl per Skript, als auch per händischem Ausführen mit hart-codierten Pfaden, Datum etc. klappt alles einwandfrei!
Ich würde aber gern verstehen, woher diese Fehlermeldung stammt.

[JTH]

Man könnte dem cp-Aufruf hier nochmal ein -v mitgeben. Mit Glück gibt das nen Indikator, bei welcher Quelle oder welchem Ziel es hapert.

Nebenbei, ich kann nicht ganz nachstellen, in welchem Szenario cp die Meldung

Code: Alles auswählen

cp: „dir/irgend/ein/Ordner“: Datei oder Verzeichnis nicht gefunden

überhaupt ausgibt (das könnt zum Eingrenzen helfen). In src/cp.c und po/de.po der coreutils tauchen nur Meldungen auf, die noch wenigstens einen kurzen weiteren Hinweis angeben.

Wenn die angegebene Quelldatei nicht existiert:

Code: Alles auswählen

$ LANGUAGE=de_DE cp non_existent foobar
cp: der Aufruf von stat für 'non_existent' ist nicht möglich: Datei oder Verzeichnis nicht gefunden

Wenn der Zielordner (noch) nicht existiert:

Code: Alles auswählen

$ LANGUAGE=de_DE cp -t non_existent foobar
cp: Zielverzeichnis 'non_existent': Datei oder Verzeichnis nicht gefunden

Oder ist in dem Zitat das „Zielverzeichnis“ unterschlagen?

da sie nicht auf der root-Partition liegen.

Geht es um ein „exotisches“ Dateisystem? Sind Dateien oder Ordner involviert, die einem anderen als dem aufrufenden Benutzer gehören?

[mrserious]

In der Tat liegen die Daten auf ZFS.
Aber: Ich habe auch bereits alles auf XFS nachgestellt (1 zu 1 kopiert) und erhalte den selben Fehler.
Das würde ich jetzt also erstmal ausschließen.
Für den Test läuft erstmal alles mit root-Rechten, das sollte also passen.

Edit: Das Slash im Quellverzeichnis ist m.E. korrekt.
Der Quellordner liegt tatsächlich direkt unterhalb von / und ist hart im Skript kodiert.
Zumindest war es vorher ganz genauso.

[Meillo]

Ich moechte meine Hinweise von oben nochmal wiederholen, denn die werden uns der Loesung naeher bringen:

Wenn du sagst, dass etwas kopiert wird, dann wende das Script doch mal ohne die Datumsbedingung an, dann sollten *alle* Dateien darin kopiert werden. Dann kannst du den Ausgangs- und Zielordner mit `diff -rq' vergleichen, ob auch wirklich keine fehlt.

Zum Debuggen kannst du mit `set -x' die Ausgabe der ausgefuehrten Befehle einschalten oder einfach zwischen `-exec' und `cp' ein `echo' setzen, dann wird der Kopierbefehl nicht ausgefuehrt, sondern im Terminal ausgegeben. Vielleicht faellt da irgendwas auf.

[Meillo]

Edit: Das Slash im Quellverzeichnis ist m.E. korrekt.
Der Quellordner liegt tatsächlich direkt unterhalb von / und ist hart im Skript kodiert.
Zumindest war es vorher ganz genauso.

Aber wieso fehlt er in der Fehlerausgabe? Ich kann mir nicht erklaeren, wie das passieren kann (jedenfalls nicht durch den Code, den du uns gepostet hast).

[mrserious]

So!

Endlich Zeit dafür gehabt
Also: Ohne Datumsangabe:

Code: Alles auswählen

find /quelle -type f -exec cp --parents -at /ziel {} +

Läuft wieder durch mit der bekannten Meldung "Datei oder Verzeichnis nicht gefunden", aber: "diff -rq" scheint hier nichts sinnvolles zu liefern?
Ich habe mir sogar die Mühe gemacht, von Hand zu schauen: Es sind alle Dateien im Zielverzeichnis, /quelle und /ziel sind somit identisch.

Den Rest probiere ich gleich noch aus

Warum das Slash fehlt kann ich mir tatsächlich auch nicht erklären!


Edit: Für den Test liegen beide Verzeichnisse auf XFS und was mich so stark irritiert:
Außer des Updates auf Debian 12 wurde nichts verändert.
Skripte, Pfade, ... alles identisch.

[Meillo]

"diff -rq" scheint hier nichts sinnvolles zu liefern?

Keine Ausgabe bedeutet bei diff, dass die beiden Verzeichnisse identisch sind. Also alles gut.


Nun mal sehen, wie die Ausgabe mit `echo' oder `set -x' aussieht. Dort sollte sich der in der Fehlermeldung erwaehnte Pfad wohl irgendwo finden lassen. (Es waere gut wenn du eine nicht oder moeglichst wenig anonymisierte Ausgabe posten koenntest.)

[mrserious]

Guten Morgen,

entschuldige, ich habe momentan wenig Zeit.
Kurzes Update:

Ich verstehe total, was du mit dem Anonymisieren meinst.
Mein Problem ist: Die Original-Verzeichnisse sind etliche TB groß.
Mir bleibt hier nichts anderes übrig, als das Szenario nachzustellen.
Ich mache aber alles auf dem selben Debian, den selben Mountpoints etc., es ist also so nah wie möglich an der Realität.

Was ich definitiv sagen kann: Das Skript / händisches Ausführen liefert definitiv korrekte Ergebnisse, es sind alle Dateien vorhanden (unter Debian 11 hatte ja ohnehin alles makellos funktioniert).

Ich schaue mal, möglichst bald die von dir vorgeschlagenen Tests machen zu können!


Edit:
FALSCH!
Ich habe das Skript gerade mehrere Male nacheinander laufen lassen, zwischendurch das Ziel-Verzeichnis immer wieder geleert.
Ergebnis: Verschiedene Ergebnisse!
Puh, langsam zweifle ich an mir. Was läuft denn hier falsch? Das ist doch ansich eine sehr einfache find-Zeile ohne viel Magie?

[mrserious]

Update:

Mir ist ein Test eingefallen, den ich mal eben zwischenschieben kann:

Habe die Zeile verändert:

vorher:

Code: Alles auswählen

find /quelle -type f -exec cp --parents -at /ziel {} +

nachher:

Code: Alles auswählen

cd /quelle
find . -type f -exec cp --parents -at /ziel {} +

Ergebnis: Die Fehlermeldung ist weg.
Kann sich das jemand erklären?
/quelle ist ein ganz normaler Ordner, direkt unterhalb von /, der auf einem XFS-Dateisystem liegt.
In meinen Augen ist daran nichts ungewöhnliches.

Update 2:
Ich habe den Fehler entdeckt, warum scheinbar im Zielverzeichnis Dateien fehlten:
Versehentlich lag das Ziel auf einem ZFS-Volume, das Kompression aktiviert hat.
Damit liefert "du" natürlich nicht sofort einen sinnvollen Wert.
Der Fehler geht also klar auf mich.