No such file or directory

lixx

Jonagold
Registriert
05.06.08
Beiträge
21
Hallo Leute!

Ich habe da ein Script, das mir aus einem Verzeichnis Ordner ausliest, die einer bestimmte Namenskonvention entsprechen, komprimiert und anschließend löscht. Allerdings bekomme ich beim löschen immer die Meldung "No such file or directory". Das Script funktioniert aber sonst. Also es sucht, komprimiert und die Verzeichnisse sind weg. Nur möchte ich keine Fehlermeldungen haben.

Die Scriptzeile:
Code:
find "$cleaningDir" \( -name '* [0-9]*.[0-9]' -or -name '* [0-9]*.[0-9] \[.*\]' \) -and -path '*/-Layout/*' -type d -exec cd {} \; -execdir tar -czf "{}.tar.gz" "{}" \; -exec rm -fR "{}" \; -print >> $dir/log.txt
Wenn ich nun "rm" weglasse und bei "tar" --remove-files dazugebe habe ich das gleiche Problem.

Woran könnte das liegen?

lg lixx
 

Rastafari

deaktivierter Benutzer
Registriert
10.03.05
Beiträge
18.150
Woran könnte das liegen?
1) Das "exec cd ..." ist nonsense und hat keinerlei Effekt.
2) Die Anführungszeichen um den Platzhalter {} sind überflüssig. Das -and ebenfalls.
3) Sieh dir zuerst mal nur die Liste der Treffer an. Wenn da auch Unterordner gefunden werden die den Kriterien entsprechen, dann können die logischerweise nicht mehr gepackt und/oder gelöscht werden - sie wurden bereits zusammen mit dem übergeordneten Objekt entfernt.
 

lixx

Jonagold
Registriert
05.06.08
Beiträge
21
Danke für Deine Antwort!

1) Das "exec cd ..." ist nonsense und hat keinerlei Effekt.
Das ist sogar sehr wichtig. wird das nicht gemacht, dann wird mit tar der gesammte Pfad archiviert und das Zielverzeichnist steckt dann in unendlich vielen Ordern und eine Direktive die das verhindert habe ich nicht gefunden.

2) Die Anführungszeichen um den Platzhalter {} sind überflüssig. Das -and ebenfalls.
Nützt nichts? Schadet nichts ... :p ... ist nur zur Sicherheit, da die Dateien Leerzeichen enthalten. Das Script ist schon älter und es war einmal notwendig. Auf jeden Fall, ohne dem funktioniert es auch nicht.

3) Sieh dir zuerst mal nur die Liste der Treffer an. Wenn da auch Unterordner gefunden werden die den Kriterien entsprechen, dann können die logischerweise nicht mehr gepackt und/oder gelöscht werden - sie wurden bereits zusammen mit dem übergeordneten Objekt entfernt.
Da sind keine Weiteren. Verwende erst mal nur Testordner.

Wenn ich z.B. ...
tar --remove-files -czf "testdir.tar.gz" "testdir"
... ausführe, dann werden zwar alle Dateien gelöscht, aber die Verzeichnisse nicht.

# tar --remove-files -czf "testdir 0.1.tar.gz" "testdir 0.1"
tar: ./._testdir 0.1: Cannot unlink: No such file or directory
tar: testdir 0.1/._.DS_Store: Cannot unlink: No such file or directory
tar: testdir 0.1/._subdir: Cannot unlink: No such file or directory
tar: testdir 0.1/subdir/._.DS_Store: Cannot unlink: No such file or directory
...

Wo er aber die Dateien mit dem "._" davor findet ist mir rätselhaft ...

Das Script hat bei einer früheren Version von MacOS schon einmal funktioniert ... o_O
 

Rastafari

deaktivierter Benutzer
Registriert
10.03.05
Beiträge
18.150
Das ist sogar sehr wichtig.
Das "--execdir" führt den darauffolgenden Befehl am Fundort des Suchtreffers aus.
Anders gesagt: Es impliziert ein umschliessendes...
Code:
pushd "$(dirname "[I]$Treffer[/I]")"; [I][COLOR="DimGray"]do_cmd;[/COLOR][/I] popd
...um den angegebenen Befehl herum. Das darin benutzte {} ersetzt dann nur noch den von dort aus relativen Pfad, keinen absoluten mehr. Es tut also genau das was du brauchst, um von tar den richtigen Teilbaum erfassen zu lassen.

Welchen Sinn würdest du denn auch darin sehen, ein gerade eben frisch erstelltes Archiv (innerhalb des zu archivierenden Ordners angelegt?????) gleich im nächsten Befehl sofort wieder zu löschen?? Genau das würde nämlich passieren, wenn das "--exec cd {}" tatsächlich so wirken würde wie du denkst, dass es das tut.

Nützt nichts? Schadet nichts ... :p ... ist nur zur Sicherheit, da die Dateien Leerzeichen enthalten.
Macht doch nichts. Es findet gar kein "word splitting" durch die Shell statt, also brauchst du dich auch nicht davor zu schützen. Das Paar geschweifter Klammern ist immer genau ein Wort und damit auch ein Argument. Auch wenn es Tonnen von Whitespace beinhaltet. (Selbst dann wenn es NUR aus Whitespace bestehen würde.)

Die von dir eingegebenen Anführungszeichen werden übrigens von der Shell entfernt, noch bevor das find überhaupt gestartet wird !!!!
Anders gesagt: Du hast überhaupt nicht den Suchtreffer in Gänsefüsschen gepackt, sondern genau diesen literalen String hier: {}
Genau diese zwei Zeichen, Bracket auf und wieder zu. Kein Whitespace drin, den man schützen müsste. Ganz sicher nicht. :)

Wo er aber die Dateien mit dem "._" davor findet ist mir rätselhaft ...
Das sind die AppleSingle-codierten Resourceforks der Dateien, die tar nur implizit erstellt um sie mit in das Archiv einpacken zu können. Das tar-Format ist selbst nicht Multifork-fähig, genau wie zB auch FAT32 oder das UFS Dateisystem. Genauso wie beim kopieren der Datei auf ein solches "Nicht-HFS" Dateisystem müssen auch hier die Resourceforks vom Datafork gesplittet und als separate Datei betrachtet werden. Beim extrahieren des Archivs fügt tar dann die zusammengehörigen Forks wieder zu einer einzigen Datei mit zwei Forks zusammen.
Guckstdu hierzu mal das an:
Code:
man SplitForks
man FixupResourceForks
Genau das wird von der OS X Version von tar implizit immer mit erledigt. (Und auch von fast allen anderen Befehlen, sobald ein Dateisystem oder -format zum Zug kommt, das Resourceforks nicht nativ unterstützt.)
 

lixx

Jonagold
Registriert
05.06.08
Beiträge
21
Danke für die ausführliche Antwort. Jetzt wird auch einiges klar. Habe auch die Zeile angepasst und es wird tatsächlich nicht mehr der gesammte Pfad archiviert.

Code:
find "$cleaningDir" \( -name '* [0-9]*.[0-9]' -or -name '* [0-9]*.[0-9] \[.*\]' \) -path '*/-Layout/*' -type d -execdir tar -czf {}.tar.gz {} \; -exec rm -fR {} \; -print >> $dir/log.txt
Aber das Problem mit "No such file or directory" bleibt trotzdem :(
 

drlecter

Wöbers Rambur
Registriert
04.11.06
Beiträge
6.442
Was wird angezeigt wenn du nur suchen lässt. Schaue dir mal die Reihenfolge an. So ein ähnliches Problem hatte ich vor langer Zeit auch mal. Ich müsste aber nach der Lösung noch einmal suchen.
 
  • Like
Reaktionen: awk

lixx

Jonagold
Registriert
05.06.08
Beiträge
21
Schon mal über die Verwendung der viel simpleren Direktive -delete nachgedacht?
(Löscht umfangreiche Ordner auch viel schneller als ein "-exec rm ...")

Diese Direktive muss ich wohl übersehen haben ... aber sie funzt bei mir nicht. Habe die Zeile mal abgespeckt, ... aber nix.

Code:
find "$cleaningDir" \( -name '* [0-9]*.[0-9]' -or -name '* [0-9]*.[0-9] \[.*\]' \) -path '*/-Layout/*' -type d -delete

Ich versteh' das nicht ...
 

CloneOfMyself

Weigelts Zinszahler (Rotfranch)
Registriert
24.02.07
Beiträge
253
Code:
find -d ...
vielleicht. das sucht (und löscht somit) von unten nach oben...
 

Rastafari

deaktivierter Benutzer
Registriert
10.03.05
Beiträge
18.150
Code:
find -d ...
vielleicht. das sucht (und löscht somit) von unten nach oben...
Trallali, trallala...
man find:
Code:
[size="-1"][I][COLOR="Blue"][B]-delete[/B][/COLOR]
   [COLOR="DarkSlateGray"]Delete found files and/or directories.
   Always returns true.
   This executes from the current working directory as find recurses
   down the tree. It will not attempt to delete a filename with
   a `/' character in its pathname relative to `.' for security reasons.[/COLOR]
   [COLOR="Blue"]Depth-first traversal processing is implied by this option.[/COLOR][/I][/size]
 

lixx

Jonagold
Registriert
05.06.08
Beiträge
21
Ich glaub das langsam nicht mehr. Was ist da bloß falsch?

Jetzt versuche ich nur noch per Terminal mit einer ganz abgespeckten Variante:
Code:
find -d /Volumes/Jobs -name "testdir 0.1" -delete
Mit oder ohne "-d": nix
Als admin und sudo: nix
Ohen -delete oder mit -print gibt er mir die gewünschten Dateien aus.
die Dateirechte sind auf einen "Normalbenutzer", also mich, gesetzt. Habe noch die ACL-Werte mit chmod -R -N "/Volumes/Jobs/testdir" entfernt uns sind jetzt "ich:staff". Die Rechte sind "drwx---r-x".

Aber nix, nix, nix!!!
 

lixx

Jonagold
Registriert
05.06.08
Beiträge
21
Jetzt reichte es mir. Habe das ganze als Schleife gebaut und es läuft.

Aber danke für die Hilfe !!!

lg lixx
 

drlecter

Wöbers Rambur
Registriert
04.11.06
Beiträge
6.442
Jetzt reichte es mir. Habe das ganze als Schleife gebaut und es läuft.

Aber danke für die Hilfe !!!

lg lixx
Es liegt (wenn ich das damals bei mir richtig gesehen habe) an der Reihenfolge wie was gefunden und übergeben wird. Ich hatte das ganze dann einfach in Perl (somit konnte ich noch etwas mehr einbauen) umgesetzt.