Papierkörbe zyklisch leeren

Skript zum zyklischen Leeren von Papierkörben auf DXP-Systemen.

HAFTUNGSAUSSCHLUSS:
Nutzung erfolgt ausschließlich auf eigene Gefahr! Keine Garantie, kein Support, keine Haftung – weder für Datenverlust noch Systemschäden. Jegliche Verantwortung liegt vollständig beim Nutzer.

Hinweis: Das Skript leert alle Papierkörbe (@Recycle und #recycle) tatsächlich. Fehlerhafte Pfade oder Tippfehler können zu Datenverlust führen; gelöschte Dateien sind nicht wiederherstellbar. Vor Einsatz unbedingt Pfade prüfen und Backups anlegen.

Anpassungen, Erweiterungen oder eigene Änderungen am Skript sind ausdrücklich möglich und können nach individuellen Anforderungen vorgenommen werden – erfolgen jedoch ebenfalls vollständig auf eigene Verantwortung.

Persönlicher Hinweis: Das Skript läuft bei mir seit Monaten zuverlässig und fehlerfrei; der obenstehende Haftungsausschluss bleibt davon unberührt und gilt weiterhin in vollem Umfang.


Dieses Skript automatisiert das Leeren von Papierkörben auf den angegebenen Volumes und Shared-Foldern. Es durchsucht die System-Papierkörbe (@Recycle) sowie die Shared-Folder-Papierkörbe (#recycle) und entfernt deren Inhalte. Jede Aktion wird in einer Log-Datei protokolliert, sodass nachvollziehbar ist, wann welche Papierkörbe geleert wurden.

  • Version 1.0.1

    • igomyway
    • August 3, 2026 at 7:22 AM
    • 4.9 kB
    • 2 Downloads

    Version 3 – Änderungen gegenüber Version 1:

    Neu in dieser Version:

    • Dynamische Suche statt fester Pfad-Liste
    Das Skript findet @Recycle- und #recycle-Ordner jetzt automatisch
    in allen Volumes (find /volume[0-9] … -name '@Recycle' bzw.
    '#recycle'), statt sie fest im Skript hinterlegt zu haben. Neue
    Volumes oder Freigaben werden dadurch automatisch mit erfasst,
    ohne dass das Skript manuell angepasst werden muss.


    Danke an karl-heinz-lnx für den Denkanstoß dazu und an Tommes für
    die Anmerkung zu -exec vs. xargs.

    • Btrfs-Snapshots werden ausgeschlossen (-prune)
    Ohne diesen Ausschluss findet find auch Papierkorb-Ordner
    innerhalb von Snapshots. Die sind aber read-only, ein rm schlägt
    dort zwangsläufig fehl und wurde fälschlich als Fehler gezählt.
    Im eigenen Test führte das Fehlen von -prune zu 18 Fehlmeldungen
    aus reinen Snapshot-Kopien – die eigentliche Löschung der
    aktuellen Papierkörbe lief dabei einwandfrei. Wer eigene
    Snapshots nutzt, sollte -prune unbedingt drin lassen.

    • Größen- und Dateianzahl-Logging
    Vor dem Löschen wird pro Ordner erfasst, wie viele Dateien und
    wie viel Speicherplatz betroffen sind. Das landet mit im Log.

    • Echte Fehlerbehandlung mit korrektem Exit-Code
    Vorher lief das Skript immer mit Exit-Code 0 durch, auch wenn
    ein rm fehlgeschlagen ist – Cronicle (oder jeder andere Scheduler)
    konnte einen fehlgeschlagenen Lauf also nicht erkennen. Jetzt
    werden Fehler gezählt und das Skript beendet sich bei mindestens
    einem Fehler mit Exit-Code 1.

    • Automatische Log-Rotation
    Die Log-Datei wuchs bisher unbegrenzt. Jetzt wird sie automatisch
    auf eine konfigurierbare maximale Zeilenanzahl gekürzt.

    • Zusammenfassungszeile am Ende jedes Laufs
    Zeigt auf einen Blick: Anzahl gelöschter Dateien, freigegebener
    Speicherplatz, Anzahl Fehler.

    Anpassungshinweise (siehe auch Kommentare im Skript):
    - LOGFILE-Pfad an eure Umgebung anpassen
    - Falls ihr das Skript in einem Docker-Container (z. B. Cronicle)
    ausführt, der eure Volumes unter einem anderen Mount-Punkt
    einbindet (z. B. /app/volume1 statt /volume1), muss der
    Suchpfad im find-Befehl entsprechend angepasst werden
    - MAX_LINES nach Bedarf einstellen.

    Getestet unter UGOS auf einer DXP2800 mit Cronicle als
    Docker-Container.

    (Bei der Formulierung dieser Versionsbeschreibung hat mir eine KI
    unter die Arme gegriffen.)

  • Version 1.0.0

    • igomyway
    • March 1, 2026 at 4:38 PM
    • 1.01 kB
    • 21 Downloads
March 1, 2026 at 5:51 PM

Hi!

Kurze Frage: Warum beginnen alle deine Pfade mit /app ?

Vorschlag: Wäre es nicht einfacher, mit dem find Befehl nach den Ordnern @Recycle und #recycle in sämtlichen Volumes zu suchen um deren Inhalt in einem weiteren Schritt zu löschen?

Du kannst dir mit find zunächst alle Ordner auf der Kommandozeile ausgeben lassen mit…

Code
find /volume[0-9] -type d -name '@Recycle' -print

bzw.

Code
find /volume[0-9] -type d -name '#recycle' -print

Wenn du mit dem Ergebnis zufrieden bist, kannst du dem find Befehl sagen, das er anschließend alle Inhalte der gefundenen Ordner löschen soll. Das könnte dann z.B. in etwa so aussehen

Achtung: ich habe den Nachfolgenden Befehl in der Form nicht getestet, sondern mir nur die Syntax genauer angeschaut

Code
find /volume[0-9] -type d -name '@Recycle' -exec rm -rf {}/* \;

Auch müsste das alles mit Root-Rechten bzw. sudo ausgeführt werden. Von daher ist das ganze eh mit Vorsicht zu genießen, weil ein rm -rf absolut Böse ist.
March 4, 2026 at 7:19 PM

Bin kein Freund vom -exec Statement unter find, aber das nur am Rande, würde das immer mit xargs lösen. Finde Deine Lösung auch eleganter, als das physische Feststellen in mehreren Arrays. Tommes hat immerhin mal RegEx benutzt 😁