1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies. Weitere Informationen

No such file or directory

Dieses Thema im Forum "Unix & Terminal" wurde erstellt von lixx, 06.07.09.

  1. lixx

    lixx Jonagold

    Dabei seit:
    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
     
  2. Rastafari

    Rastafari Golden Noble

    Dabei seit:
    10.03.05
    Beiträge:
    17.896
    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.
     
  3. lixx

    lixx Jonagold

    Dabei seit:
    05.06.08
    Beiträge:
    21
    Danke für Deine Antwort!

    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.

    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.

    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
     
  4. Rastafari

    Rastafari Golden Noble

    Dabei seit:
    10.03.05
    Beiträge:
    17.896
    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.

    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. :)

    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.)
     
  5. lixx

    lixx Jonagold

    Dabei seit:
    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 :(
     
  6. drlecter

    drlecter Wöbers Rambur

    Dabei seit:
    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.
     
    awk gefällt das.
  7. Rastafari

    Rastafari Golden Noble

    Dabei seit:
    10.03.05
    Beiträge:
    17.896
    Schon mal über die Verwendung der viel simpleren Direktive -delete nachgedacht?
    (Löscht umfangreiche Ordner auch viel schneller als ein "-exec rm ...")
     
  8. lixx

    lixx Jonagold

    Dabei seit:
    05.06.08
    Beiträge:
    21
    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 ...
     
  9. Rastafari

    Rastafari Golden Noble

    Dabei seit:
    10.03.05
    Beiträge:
    17.896
    Die Objekte werden ohne das delete auch wirklich gefunden?
    Du hast Schreibrechte?
     
  10. CloneOfMyself

    CloneOfMyself Weigelts Zinszahler (Rotfranch)

    Dabei seit:
    24.02.07
    Beiträge:
    253
    Code:
    find -d ...
    vielleicht. das sucht (und löscht somit) von unten nach oben...
     
  11. Rastafari

    Rastafari Golden Noble

    Dabei seit:
    10.03.05
    Beiträge:
    17.896
    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]
     
  12. lixx

    lixx Jonagold

    Dabei seit:
    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!!!
     
  13. lixx

    lixx Jonagold

    Dabei seit:
    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
     
  14. drlecter

    drlecter Wöbers Rambur

    Dabei seit:
    04.11.06
    Beiträge:
    6.442
    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.
     

Diese Seite empfehlen