Löschen nach Alter | atime / mtime / ctime

[peterhoffmann]

Hallo!

Ich habe einen gemeinsamen Ordner, den ich als Dateimüllkippe verwende. Das wären z.B. mal schnelle Uploads vom Handy auf das NAS um ein Foto zu bearbeiten, quick&dirty... dabei "vergisst" man gerne mal diese Dateien.

Nun möchte ich regelmäßig ein Script laufen lassen, welches diesen Ordner kontrolliert und alle Dateien, die älter als 365 Tage sind, löschen. Das Script ist fertig, im Grunde ein Einzeiler mit find.

Unschlüssig bin ich mir bei der Auswahl vom Alter, da es drei verschiedene Zeiten gibt.
atime (Access-Stempel)
mtime (Modification-Stempel)
ctime (Change- oder Creation-Stempel)

Beispiel:

Filename : testdatei12.jpg
atime    : 2020-12-12 17:34:47.172285525 +0100
mtime    : 2008-02-02 16:28:32.000000000 +0100
ctime    : 2020-12-12 16:57:37.820513823 +0100

mtime fällt raus, da ältere Dateien sofort gelöscht werden würden.
Nun bleibt nur noch atime und ctime. Im Moment tendiere ich zu atime, da eine ins Verzeichnis kopierte Datei wohl dieses Datum erhält, sowie bei einem Zugriff z.B. drei Tage später dieses Datum erneuert wird. Das würde sicherstellen, dass wirklich nur Dateien gelöscht werden, die seit 365 Tagen nicht angefasst wurden.

Beispiel:

Filename : testdatei34.jpg
atime    : 2020-12-13 16:56:59.345184400 +0100
mtime    : 2020-12-03 16:56:24.727728200 +0100
ctime    : 2020-12-10 18:30:05.588095446 +0100

Bin ich auf dem richtigen Pfad?
Oder habe ich einen Denkfehler?

 

[framp]

Interessante Frage. Hier hat jemand auch schon die Frage gestellt.

atime is last accessed time, mtime the last modified time (when you changed the content of the file), ctime is the change time, i.e. the last time the inode for that file has been changed (e.g. you changed permissions, or renamed the file).

Daraus schliesse ich die mtime ist die richtige die Du benutzen solltest.

 

[peterhoffmann]

mtime ist die richtige die Du benutzen solltest.

Warum?

Ich habe mtime ausgeschlossen, weil sie nur bei einer Modifizierung aktualisiert wird. Wenn ich also eine ältere Datei dorthin kopiere, würde sie beim nächsten Scriptdurchlauf sofort gelöscht werden (siehe Beispiel testdatei12.jpg).

Filename : testdatei12.jpg
atime    : 2020-12-12 17:34:47.172285525 +0100
mtime    : 2008-02-02 16:28:32.000000000 +0100
ctime    : 2020-12-12 16:57:37.820513823 +0100

 

[Benares]

Es wundert mich etwas, dass mtime älter als ctime sein sollte Muss ich mal testen.

Edit: Hast du dir das mal mit "stat <dateiname>" angeschaut. oder woher stammen deine Ausgaben?

 

[stefan_lx]

wenn eine Datei mit der FileStation auf die Syno gelegt wird, ist mtime das Original-Datum der Datei, ctime und atime ändern sich auf das aktuelle Datum (jedenfalls war das bei mir gerade so und die Uhrzeiten unterscheiden sich nur irgendwo bei den Hundertstelsekunden)

für Peter ist atime dann wohl richtig

Stefan

 

[peterhoffmann]

deine Ausgaben

stat -c "Filename : %n
atime    : %x
mtime    : %y
ctime    : %z
" *

 

[luddi]

Hier gibt es eine interessante Matrix welche zeigt wann welcher Zeitstempel bei welcher Operation angepasst wird.
Das könnte evtl. bei deiner Entscheidung helfen.

Zeitstempel von Dateien – Linupedia (linux-club.de)

 

[Benares]

Ich hab mal folgendes getestet:

root@DS415:~# touch xxx
root@DS415:~# stat xxx
  File: ‘xxx’
  Size: 0               Blocks: 0          IO Block: 4096   regular empty file
Device: 900h/2304d      Inode: 24420       Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2020-12-13 20:03:05.333287183 +0100
Modify: 2020-12-13 20:03:05.333287183 +0100
Change: 2020-12-13 20:03:05.333287183 +0100
 Birth: -
root@DS415:~# chmod 777 xxx
root@DS415:~# stat xxx
  File: ‘xxx’
  Size: 0               Blocks: 0          IO Block: 4096   regular empty file
Device: 900h/2304d      Inode: 24420       Links: 1
Access: (0777/-rwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2020-12-13 20:03:05.333287183 +0100
Modify: 2020-12-13 20:03:05.333287183 +0100
Change: 2020-12-13 20:03:23.873084638 +0100
 Birth: -
root@DS415:~# vi xxx
root@DS415:~# stat xxx
  File: ‘xxx’
  Size: 0               Blocks: 0          IO Block: 4096   regular empty file
Device: 900h/2304d      Inode: 24420       Links: 1
Access: (0777/-rwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2020-12-13 20:03:48.581814709 +0100
Modify: 2020-12-13 20:03:52.011777240 +0100
Change: 2020-12-13 20:03:52.052776792 +0100
 Birth: -
root@DS415:~# vi xxx
root@DS415:~# stat xxx
  File: ‘xxx’
  Size: 3               Blocks: 8          IO Block: 4096   regular file
Device: 900h/2304d      Inode: 24420       Links: 1
Access: (0777/-rwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2020-12-13 20:09:02.562386211 +0100
Modify: 2020-12-13 20:09:09.271312983 +0100
Change: 2020-12-13 20:09:09.321312438 +0100
 Birth: -

Anfangs sind also alle Zeiten gleich. Ändern sich Attribute, ändert sich ctime. Beim editieren ändert sich atime beim Öffnen und mtime gefolgt von ctime beim Speichern.
So, nun such dir etwas aus, was du unter "Alter" verstehst. Vermutlich ist ctime sinnvoll.

 

[luddi]

Vermutlich ist ctime sinnvoll.

In meinem Fall verwende ich auch den Zeitstempel "ctime". Aber was Sinn ergibt hängt sicher vom jeweiligen Anwendungsfall ab.
Aus dem Beitrag und der Fragestellung von @peterhoffmann würde ich aus meiner Sicht ctime verwenden.

Hier wie schon erwähnt aus dem Link zuvor eine Übersichtsmatrix zu den wesentlichen Unterschieden atime/mtime/ctime:

Quelle

 

[peterhoffmann]

mtime werde ich nicht nehmen.
Im Moment bin ich mir bei c oder a noch nicht sicher. Mein Testlauf läuft im Moment auf a-time. Das beobachte ich mal ein paar Tage, da ich die Zeiten je nach Größe auf 1, 2, 3 oder 4 Tage runtergesetzt habe.

Vielen Dank für eure Sicht- und Hinweise. Auch der Test, sowie die schöne Tabelle machen es mir leichter.

 

[AndiHeitzer]

Mein Trigger ist 'mtime' und damit bin ich sehr zufrieden.

 

[peterhoffmann]

Mein Trigger ist 'mtime'

Alles eine Frage wofür man was benötigt. Der Deckel muss auf den Topf passen.

 

[luddi]

Alles eine Frage wofür man was benötigt.

Genau so sehe ich das auch. Es gibt hier kein richtig oder falsch sondern nur den individuellen Anwendungsfall.