[BASH] Zoek bestanden GEMAAKT ouder dan X

[Anoniem: 1179574]

Hoi,

Ik ben al een tijdje aan het worstelen met een simpel commando maar kom er niet aan uit.

Ik heb een SAMBA share en alles wat in die ene share gezet wordt mag maar maximaal een maand erin staan en daarna dient het verwijderd te worden. Er kan dus te allen tijde iets erin worden gezet maar alleen de bestanden en directories die ouder zijn dan 30 dagen mogen worden verwijderd ( kleine noot, als de directory ouder is maar files IN die directory NIET dan mag de map dus ook niet weg).

Ik worstel met MODIFICATION date en CREATION date.

Zelf kwam ik hierop uit:

code:

find /mnt/map/ -ctime -30

Klopt deze line wel?

Als er namelijk een bestand in wordt gezet die 5 jaar oud is dan moet deze alsnog 30 dagen in deze map blijven staan, daarna pas weg. Gaat dit goed zo?

[dev10]

Waar je even rekening mee moet houden met find, is dat ctime iets anders is dan de datum waarop het bestand aangemaakt is. ctime is de datum waarop de properties van het bestand of de inhoud van het bestand zijn aangepast. Zie ook: https://nicolasbouliane.c...ference-mtime-ctime-atime

De regel moet je iets aanpassen:

code:

find -type f /mnt/map/ -mtime +30

De +30 parameter toont alle bestanden die meer dan 30 dagen voor het laatst zijn aangepast. De parameter -type f zorgt er voor dat je alleen bestanden terugkrijgt.

Lege mappen kun je op deze manier ook heel eenvoudig vinden:

code:

find -type d -empty

Ik zal niet gelijk de hele commando's voor je uittypen, want daar leer je helemaal niks van, maar er is ook een parameter bij het find commando waarmee je bestanden en mappen direct kunt verwijderen.

[Sebas1979]

Moet een bestand dat er op datum D ingezet is en op datum D+15 gewijzigd wordt, op datum D+30 verwijderd worden?

Zo nee, dan kun je volgens mij wel uit met de mtime switch.

Als dat wel verwijderd moet worden, denk ik dat je iets met ls en diff moet gaan doen (dagelijks lijst van bestanden listen, en vergelijken met die van 30 dagen terug, bestanden die in lijst van 30 dagen terug al bestonden verwijderen)

[c-nan]

dev10 schreef op maandag 14 februari 2022 @ 09:21:
Waar je even rekening mee moet houden met find, is dat ctime iets anders is dan de datum waarop het bestand aangemaakt is. ctime is de datum waarop de properties van het bestand of de inhoud van het bestand zijn aangepast. Zie ook: https://nicolasbouliane.c...ference-mtime-ctime-atime

De regel moet je iets aanpassen:

code:

find -type f /mnt/map/ -mtime +30

De +30 parameter toont alle bestanden die meer dan 30 dagen voor het laatst zijn aangepast. De parameter -type f zorgt er voor dat je alleen bestanden terugkrijgt.

Lege mappen kun je op deze manier ook heel eenvoudig vinden:

code:

find -type d -empty

Ik zal niet gelijk de hele commando's voor je uittypen, want daar leer je helemaal niks van, maar er is ook een parameter bij het find commando waarmee je bestanden en mappen direct kunt verwijderen.

Met jou oplossing vind je bestanden die 30+ dagen niet zijn aangepast, maar als je dus een bestand hebt die je iedere dag aanpast zal deze nooit in je lijstje terugkomen. Terwijl dat niet de vraag van TS is

Wat TS wilt is met enkel find niet mogelijk. Je moet een database aanleggen waarin je het een en ander vergelijkt.

[Anoniem: 1179574]

En what about atime dan?

[c-nan]

Anoniem: 1179574 schreef op maandag 14 februari 2022 @ 09:48:
En what about atime dan?

Als ik iedere dag hetzelfde bestandje uitlees, dan blijft het bestandje voor een eeuwigheid bestaan.

[c-nan]

Een bestaande file:

code:

[root@server tnet]# stat ~/file
  File: ‘/root/file’
  Size: 6           Blocks: 8          IO Block: 4096   regular file
Device: fd00h/64768d    Inode: 606190822   Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Context: unconfined_u:object_r:admin_home_t:s0
Access: 2021-02-03 16:27:29.461589134 +0100
Modify: 2021-02-03 16:27:13.351042211 +0100
Change: 2021-02-03 16:27:13.351042211 +0100
 Birth: -
[root@server tnet]#

Zowel, atime, mtime en ctime uit 2021.

Datzeflde bestand kopieer ik nu naar mijn eigen directory:

code:

[root@server tnet]# cp ~/file .
[root@server tnet]# stat file
  File: ‘file’
  Size: 6           Blocks: 8          IO Block: 4096   regular file
Device: fd00h/64768d    Inode: 1180809879  Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Context: unconfined_u:object_r:admin_home_t:s0
Access: 2022-02-14 09:54:29.169429301 +0100
Modify: 2022-02-14 09:54:29.169429301 +0100
Change: 2022-02-14 09:54:29.169429301 +0100
 Birth: -
[root@server tnet]#

Zoals je ziet is atime, mtime en ctime aangepast naar nu/vandaag.

Ga ik nou in plaats van kopieren het bestand verplaatsen:

code:

[root@server tnet]# rm file
rm: remove regular file ‘file’? y
[root@server tnet]# mv ~/file .
[root@server tnet]# stat file 
  File: ‘file’
  Size: 6           Blocks: 8          IO Block: 4096   regular file
Device: fd00h/64768d    Inode: 606190822   Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Context: unconfined_u:object_r:admin_home_t:s0
Access: 2022-02-14 09:54:29.169429301 +0100
Modify: 2021-02-03 16:27:13.351042211 +0100
Change: 2022-02-14 09:54:43.308044721 +0100
 Birth: -
[root@server tnet]#

Dan zie je dat atime en ctime veranderen, maar mtime blijft ongewijzigd.

Maar breng ik nou een wijziging aan in het bestand, dan zie je dat mtime en ctime wijzigen:

code:

[root@server tnet]# echo bla >> file 
[root@server tnet]# stat file
  File: ‘file’
  Size: 11          Blocks: 8          IO Block: 4096   regular file
Device: fd00h/64768d    Inode: 1180809880  Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Context: unconfined_u:object_r:admin_home_t:s0
Access: 2022-02-14 09:55:05.576439007 +0100
Modify: 2022-02-14 09:59:30.945220808 +0100
Change: 2022-02-14 09:59:30.945220808 +0100
 Birth: -
[root@server tnet]#

Zodra ik het bestand uitlees zie je dat atime veranderd:

code:

[root@server tnet]# cat file 
bar
bla
[root@server tnet]# stat file
  File: ‘file’
  Size: 11          Blocks: 8          IO Block: 4096   regular file
Device: fd00h/64768d    Inode: 1180809880  Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Context: unconfined_u:object_r:admin_home_t:s0
Access: 2022-02-14 10:00:14.501036062 +0100
Modify: 2022-02-14 09:59:30.945220808 +0100
Change: 2022-02-14 09:59:30.945220808 +0100
 Birth: -
[root@server tnet]#

[Creepy]

Even een tikje door naar Non-Windows Operating Systems waar Bash beter thuis hoort dan in Softwareontwikkeling

[Anoniem: 1179574]

Ja okay maar als een bestand dus gedurende 30 dag niet wordt geopend dan wordt hij getriggerd (atime), toch? Dan is dat eigenlijk voor mij voldoende mits mijn theorie klopt.

[Big Mama]

Er bestaat zoiets als een creation time. Maar die is niet eenvoudig te achterhalen, in ieder geval niet met de standaard tooltjes. Bijvoorbeeld: stat toont dat er een "birth" veld is, maar geeft niet weer wat de waarde is.

code:

# stat /etc/hosts
  File: /etc/hosts
  Size: 280             Blocks: 8          IO Block: 4096   regular file
Device: fd00h/64768d    Inode: 141270      Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2022-02-13 14:19:54.285231207 +0100
Modify: 2021-05-31 15:19:25.054724188 +0200
Change: 2021-05-31 15:19:25.054724188 +0200
 Birth: -

Met stat versie 8.31 laat hij het wel zien, maar op synology DSM 7.x is versie 8.30 aanwezig, die het niet laat zien.

Het is wel te achterhalen, maar dat is nogal een gedoe. Zie bijvoorbeeld https://unix.stackexchang...77/birth-is-empty-on-ext4

Moraal van het verhaal: met mtime (modification time) en atime (access time) is het makkelijk werken. Wil je echt de creation time hebben, dan kan het wel, maar is niet eenvoudig. De ctime (change time, NIET creation time) is niet relevant, want die geeft alleen maar aan wanneer de inode van het bestand gewijzigd is (eigenaar, mode, enz).

[ Voor 6% gewijzigd door Big Mama op 14-02-2022 11:02 ]

[Big Mama]

Anoniem: 1179574 schreef op maandag 14 februari 2022 @ 10:08:
Ja okay maar als een bestand dus gedurende 30 dag niet wordt geopend dan wordt hij getriggerd (atime), toch? Dan is dat eigenlijk voor mij voldoende mits mijn theorie klopt.

Nog iets om rekening mee te houden: soms worden filesystems vanuit performanceoverwegingen gemount met de optie 'noatime'. Dit heeft tot gevolg dat het atime veld van de inode niet wordt bijgewerkt wanneer het bestand gelezen wordt.
De mount-optie 'relatime' bestaat ook, dan wordt de access time maximaal 1 keer per periode (meestal 1 dag) bijgewerkt. Die laatste zou voor jou prima werken, maar 'noatime' dus niet.