Skriptfrage: Dateien *und* Verzeichnisse loeschen
Tach Liste. Ich lasse folgendes Skript von cron.daily ausführen: cd /home/andy/Desktop/Trash && find ./ -atime +5 | xargs rm -r > /dev/null 2>&1 Damit will ich den Trash vor dem Überlaufen bewahren. Allerdings bleiben auf diese Weise die Unterverzeichnisse bestehen, wenn auch leer. Wie muß ich denn das Skript bauen, um auch die Verzeichnisse zu erwischen? Danke. Andy -- Andreas Feile www.feile.net
* Andreas Feile schrieb am 11.Dez.2002:
Ich lasse folgendes Skript von cron.daily ausführen:
cd /home/andy/Desktop/Trash && find ./ -atime +5 | xargs rm -r > /dev/null 2>&1
Damit will ich den Trash vor dem Überlaufen bewahren. Allerdings bleiben auf diese Weise die Unterverzeichnisse bestehen, wenn auch leer. Wie muß ich denn das Skript bauen, um auch die Verzeichnisse zu erwischen?
Würdest Du die Fehlerausgabe nicht ins Nirvana schicken, sondern Dir ansehen, wüßtest Du was passiert ist. Was meinst Du, wofür Fehlerausgaben da sind? Was genau hast Du vor? Alle Verzeichnisse und Dateien löschen, die länger als 5 Tage nicht gelesen wurden. Was ist, wenn ein Verzeichnis länger als 5 Tage nicht gelesen wurde, eine Datei darin aber schon? Soll die Datei auch gelöscht werden, obwohl vor kurzem noch auf sie zugegriffen wurde? Wenn sie nicht gelöscht wird, kann aber auch das Verzeichnis nicht gelöscht werden. Das rm -r erscheint mir ein wenig doppelt gemoppelt. Einerseits bekomst Du sämtliche Dateinamen von find explizit geliefert, zum anderen sagst Du alles soll, soweit es sich um Verzeichnisse handelt mit Inhalt gelöscht werden. Da find die Verzeichnisse lesen muß, setzt es selber die atime anders. Bernd -- Was ist quoten? Quoten ist das Zitieren aus einer mail, der man antwortet. Und wie macht man es richtig? Zitate werden mit "> " gekennzeichnet. Nicht mehr als nötig zitieren. Vor den Abschnitten das Zitat, auf das man sich bezieht, mit einer Zeile Abstand oben und unten. |Zufallssignatur 12
Bernd Brodesser, Mittwoch, 11. Dezember 2002 13:46:
Was genau hast Du vor? Alle Verzeichnisse und Dateien löschen, die länger als 5 Tage nicht gelesen wurden. Was ist, wenn ein Verzeichnis länger als 5 Tage nicht gelesen wurde, eine Datei darin aber schon? Soll die Datei auch gelöscht werden, obwohl vor kurzem noch auf sie zugegriffen wurde? Wenn sie nicht gelöscht wird, kann aber auch das Verzeichnis nicht gelöscht werden.
Also ich möchte erreichen, daß alle Dateien in Trash fünf Tage, nachdem sie dorthin geschoben wurden, gelöscht werden. Bei den Verzeichnissen möchte ich dasselbe, d.h. fünf Tage nach dem Verschieben in den Trash sollen sie mitsamt der enthaltenen Unterstruktur verschwinden. Daß in einem Verzeichnis eine Datei liegt, auf die vor weniger als fünf Tagen zugegriffen wurde kann doch eigentlich nicht sein. Denn auf das, was im Trash liegt, wird (bei mir jedenfalls) überhaupt nicht mehr zugegriffen.
Das rm -r erscheint mir ein wenig doppelt gemoppelt. Einerseits bekomst Du sämtliche Dateinamen von find explizit geliefert, zum anderen sagst Du alles soll, soweit es sich um Verzeichnisse handelt mit Inhalt gelöscht werden.
Das -r habe ich angefügt, weil ich dachte, damit könnte ich eben die Unterverzeichnisse selbst auch erwischen: Ein rm -r /home würde doch zB home mitsamt jeglicher Unterstruktur beseitigen. Die Umleitung der stderr habe ich gesetzt, weil eben find auch den Trash selbst findet, den es weder löschen kann noch soll. Weil ich aber nicht wußte, wie ich es besser machen könnte habe ich einfach umgeleitet, weil ich dachte, im Übrigen funktioniert das Skript. Wie müßte ich also mein Skript umschreiben, damit ich mein Ziel erreichen kann? -- Andreas Feile www.feile.net
* Andreas Feile schrieb am 11.Dez.2002:
Bernd Brodesser, Mittwoch, 11. Dezember 2002 13:46:
Was genau hast Du vor? Alle Verzeichnisse und Dateien löschen, die länger als 5 Tage nicht gelesen wurden. Was ist, wenn ein Verzeichnis länger als 5 Tage nicht gelesen wurde, eine Datei darin aber schon? Soll die Datei auch gelöscht werden, obwohl vor kurzem noch auf sie zugegriffen wurde? Wenn sie nicht gelöscht wird, kann aber auch das Verzeichnis nicht gelöscht werden.
Also ich möchte erreichen, daß alle Dateien in Trash fünf Tage, nachdem sie dorthin geschoben wurden, gelöscht werden.
Und warum nimmst Du dafür atime? atime ist die Zeit des letzten *lesenden* Zugriffs. Einmal angeschaut und schon wird dieser Zeitstempel verändert. Besser wäre doch mtime oder ctime, die Zeit des letzten schreibenden Zugriffs, oder die Zeit der letzten I-Node-Änderung.
Bei den Verzeichnissen möchte ich dasselbe, d.h. fünf Tage nach dem Verschieben in den Trash sollen sie mitsamt der enthaltenen Unterstruktur verschwinden. Daß in einem Verzeichnis eine Datei liegt, auf die vor weniger als fünf Tagen zugegriffen wurde kann doch eigentlich nicht sein. Denn auf das, was im Trash liegt, wird (bei mir jedenfalls) überhaupt nicht mehr zugegriffen.
Keine Ahnung, ich habe kein trash. Bernd -- ROTFL = Rolling On The Floor, Laughing = Auf dem Boden wälzen, lachend. SCNR = Sorry, Could Not Resist = Sorry, Ich konte nicht wiederstehen. AFAIK = As Far As I Know = So weit ich weis|BTW = By The Way = Nebenbei bemerkt IMHO = In My Humble Opinion = meiner bescheidenen Meinung nach |Zufallssig. 9
Bernd Brodesser, Mittwoch, 11. Dezember 2002 18:32:
Also ich möchte erreichen, daß alle Dateien in Trash fünf Tage, nachdem sie dorthin geschoben wurden, gelöscht werden.
Und warum nimmst Du dafür atime? atime ist die Zeit des letzten *lesenden* Zugriffs. Einmal angeschaut und schon wird dieser Zeitstempel verändert.
Besser wäre doch mtime oder ctime, die Zeit des letzten schreibenden Zugriffs, oder die Zeit der letzten I-Node-Änderung.
Ich wollte halt den spätestmöglichen Zeitpunkt erwischen und dachte, das sei atime. Nun, damit kann ich ja noch experimentieren. Aber das Problem mit den leeren Verzeichnissen besteht ja nach wie vor. Hast Du da einen Tip für mich? -- Andreas Feile www.feile.net
* Andreas Feile schrieb am 12.Dez.2002:
Bernd Brodesser, Mittwoch, 11. Dezember 2002 18:32:
Also ich möchte erreichen, daß alle Dateien in Trash fünf Tage, nachdem sie dorthin geschoben wurden, gelöscht werden.
Und warum nimmst Du dafür atime? atime ist die Zeit des letzten *lesenden* Zugriffs. Einmal angeschaut und schon wird dieser Zeitstempel verändert.
Besser wäre doch mtime oder ctime, die Zeit des letzten schreibenden Zugriffs, oder die Zeit der letzten I-Node-Änderung.
Ich wollte halt den spätestmöglichen Zeitpunkt erwischen und dachte, das sei atime.
atime ist nicht der spätestmöglichen Zeitpunkt. Wenn ich in einer Datei schreibe, dann verändere ich zwar mtime, nicht aber atime. Bernd -- ROTFL = Rolling On The Floor, Laughing = Auf dem Boden wälzen, lachend. SCNR = Sorry, Could Not Resist = Sorry, Ich konte nicht wiederstehen. AFAIK = As Far As I Know = So weit ich weis|BTW = By The Way = Nebenbei bemerkt IMHO = In My Humble Opinion = meiner bescheidenen Meinung nach |Zufallssig. 9
Moin,
* Bernd Brodesser
* Andreas Feile schrieb am 11.Dez.2002:
Ich lasse folgendes Skript von cron.daily ausführen:
cd /home/andy/Desktop/Trash && find ./ -atime +5 | xargs rm -r > /dev/null 2>&1
Damit will ich den Trash vor dem Überlaufen bewahren. Allerdings bleiben auf diese Weise die Unterverzeichnisse bestehen, wenn auch leer. Wie muß ich denn das Skript bauen, um auch die Verzeichnisse zu erwischen?
Würdest Du die Fehlerausgabe nicht ins Nirvana schicken, sondern Dir ansehen, wüßtest Du was passiert ist. Was meinst Du, wofür Fehlerausgaben da sind?
Man sollte sie jedenfalls nur in Ausnahmefällen auf der Festplatte speichern. Denn durch die vielen geflipten Bytes können Unwuchten entstehen, die dann die Lager der Festplatte über Gebühr belasten.
Das rm -r erscheint mir ein wenig doppelt gemoppelt.
Ohne werden Verzeichnisse nicht gelöscht.
Da find die Verzeichnisse lesen muß, setzt es selber die atime anders.
Ähhh, aber doch wohl kaum bevor es den Wert auswertet, oder? Thorsten -- "But beware of the dark side... If once you start down the dark path, forever will it dominate your destiny, consume you it will..." "...Is the dark side stronger?" "No...no...no. Quicker, easier, more seductive."
participants (3)
-
Andreas Feile
-
B.Brodesser@t-online.de
-
Thorsten Haude