Ich mag Busybox ash find -exec nicht!

[Steini]

So, habt ihr Ostern gut über die Runden gebracht und alle versteckten Eier/Süßigkeiten/Leckerlis/whatever aufgespürt? Ich hab' hier noch eine Herausforderung für euch, der ich irgendwie nicht beikomme... Und zwar möchte ich die von Macs angelegten "Desktop Services Store"-Dateien von meinem NAS verbannen. Meinem eigenen Rechner habe ich das bereits abgewöhnt via...

defaults write com.apple.desktopservices DSDontWriteNetworkStores true

Aber dennoch tauchen diese lästigen Dateien auf, weil andere User eben nicht ihre Macs entsprechend konfiguriert haben und ich jetzt hinterherräumen muss. Deswegen wollte ich via Konsole die bereits angelegten Dateien löschen:

find /volume1 -name ".DS_*" -exec rm -r \"{}\" \;

Pustekuchen! Da wird nix gelöscht. Niente. Nada. Schreibe ich hingegen den Dateinamen aus, funktioniert's:

find /volume1 -name ".DS_Store" -exec rm -r \"{}\" \;

Und jetzt kommt ihr:

1. Wieso kann ich das zweite find in der Konsole erfolgreich ausführen, aber nicht via Cron?
2. Könnte mir bitte jemand verraten, wieso der Stern als Platzhalter nicht akzeptiert wird?

 

[itari]

Bei mir geht das:

Synology> /usr/bin/find /volume1 -name ".DS_*" -exec echo \"{}\" \;
/volume1/downloads/.DS_Store
...

Hab statt des rm -r gerade nur den echo verwendet, um den Dateinamen anzeigen zu lassen ...

Itari

 

[Steini]

War ja klar, dass das Problem am DAU vor dem NAS lag...

Ich habe das Sternchen ständig mit diesem Befehl genutzt:

find /volume1 -name ".ds_*" -exec rm -r \"{}\" \;

Getestet habe ich es allerdings ausgeschrieben mit ".DS_Store". Baaaaahhh!!!!

Das wirft eine weitere Frage: Welchen Schalter nutze ich, damit find beim Suchen keine Unterscheidung zwischen Groß- und Kleinschreibung macht? Weder -i noch -iname bringen mich voran.

Und die erste Frage ist noch ungeklärt:

find /volume1 -name ".DS_*" -exec rm -r \"{}\" \;

...im Crontab zeigt keine Wirkung.

 

[itari]

Installiere dir per IPKG die findutils. Damit geht dann auch der -iname.

In der crontab würde ich zunächst komplette Pfade verwenden:

/opt/bin/find /volume1 -iname ".DS_*" -exec /bin/rm -r \"{}\" \;

Itari

 

[magick]

In der crontab alle parameter (tag monat stunde etc) per TAB getrennt? Das ist zumindest der Lieblingsfehler. Der cron auf der DS ist ziemlich empfindlich was die Syntax angeht.

Und alle Kommandos mit vollem Pfad aufrufen. Der PATH ist nicht unbedingt derselbe wie bei der Shell.

 

[Steini]

Installiere dir per IPKG die findutils. Damit geht dann auch der -iname. [...]

Die sind installiert...

[...] In der crontab würde ich zunächst komplette Pfade verwenden [...]

Hab' ich auch schon erfolglos versucht...

In der crontab alle parameter (tag monat stunde etc) per TAB getrennt? [...]

Na klaro...

 

[jahlives]

Also das folgende funzt bei mir mit ipkg findutils sauber

find /path | grep ".DS_*" | xargs -n 1 rm

 

[Steini]

Also das folgende funzt bei mir mit ipkg findutils sauber [...]

Oh, du mein Held!!! Jetzt klappt's auf der Shell und im Cron perfekt:

/usr/bin/find /volume1 | grep -i ".ds_*" | xargs -n 1 rm

Noch eine Frage, die aber nicht direkt mit dem Problem zu tun hat: Wenn ich dem Cron sagen möchte, dass er bitte alle fünf Minuten einen Job anstößt, warum funktioniert das nicht mit "*/5"?

 

[jahlives]

Mir ist noch etwas potentiell gefährliches aufgefallen! Wenn das Suchmuster nicht zutrifft, dann wird der Inhalt der aktuellen Verzeichnisses aufgelistet!!! Dann wird also wohl das aktuelle Verzeichnis gelöscht!!

 

[Steini]

Nein, dem ist nicht so. Zumindest nicht nach meinen Testläufen.

 

[jahlives]

Verwende den Code NUR wenn du zuvor eine Prüfung auf diese Files gemacht hast

#!/bin/sh

if test -n $(/usr/bin/find /volume1 | grep -i ".ds_*"); then
 /usr/bin/find /volume1 | grep -i ".ds_*" | xargs -n 1 rm
fi

 

[Steini]

Wie gesagt: Nach Testläufen konnte ich nicht feststellen, dass mir irgendwas im /volume1 gelöscht wurde. Geprüft habe ich den Aufruf vorher mit:

/usr/bin/find /volume1 | grep -i ".ds_*" | xargs -n 1 ls -la

 

[jahlives]

Nein, dem ist nicht so. Zumindest nicht nach meinen Testläufen.

Stimmt du hast recht. rm verlangt immer nach einem filenamen und grep findet ja nichts. Wenn du aber ls statt rm verwendest dann wird dir trotzdem der gesamte Verzeichisinhalt angezeigt, drum habe ich befürchtet, dass rm auch alles wegputzen hätte.
Eine Fehlermeldung seitens rm solltest du aber kriegen wen du den Code auf ein Verzeichnis loslässt, das keine solchen store Dateien hat.
**edit**
Ich würde trotzdem ein kleines if test machen bevor du den Befehl anwirfst
**edit**

 

[Steini]

[...] Eine Fehlermeldung seitens rm solltest du aber kriegen wen du den Code auf ein Verzeichnis loslässt, das keine solchen store Dateien hat. [...]

Wo sollte die stehen? In den Logs? Wenn ich den Befehl in der Konsole auf ein Verzeichnis ohne DSS-Dateien absetze, bekomme ich keinerlei Feedback.

[...] Ich würde trotzdem ein kleines if test machen bevor du den Befehl anwirfst [...]

Ja, da hast du Recht: Sicher ist sicher!

 

[jahlives]

Wo sollte die stehen? In den Logs? Wenn ich den Befehl in der Konsole auf ein Verzeichnis ohne DSS-Dateien absetze, bekomme ich keinerlei Feedback.

Direkt auf der Konsole ergibt keinen Fehler, wenn solche Dateien nicht vorkommen??? Bei mir kommt

/usr/bin/find /tmp/test | grep -i ".dS_*" | xargs -n 1 rm
rm: missing operand

 

[Steini]

Liegt am AdminTool. Hatte vergessen die Ausgabe zu aktivieren mittels 2>&1. Jetzt erhalte ich beim Absetzen von...

/usr/bin/find /tmp/test | grep -i ".dS_*" | xargs -n 1 rm 2>&1

...diesen Fehler:

Usage: rm [OPTION]... FILE...