Toon posts:

[BASH] Zoek bestanden GEMAAKT ouder dan X

Pagina: 1
Acties:

Vraag


Anoniem: 1179574

Topicstarter
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:
1
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?

Beste antwoord (via Anoniem: 1179574 op 14-02-2022 11:09)


  • c-nan
  • Registratie: Juni 2008
  • Laatst online: 23:16
Een bestaande file:
code:
1
2
3
4
5
6
7
8
9
10
11
[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:
1
2
3
4
5
6
7
8
9
10
11
12
[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:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
[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:
1
2
3
4
5
6
7
8
9
10
11
12
[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:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
[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]#

Alle reacties


  • dev10
  • Registratie: April 2005
  • Laatst online: 30-01 13:14
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:
1
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:
1
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
  • Registratie: Juni 2004
  • Laatst online: 23:47
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
  • Registratie: Juni 2008
  • Laatst online: 23:16
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:
1
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:
1
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

Topicstarter
En what about atime dan?

  • c-nan
  • Registratie: Juni 2008
  • Laatst online: 23:16
Als ik iedere dag hetzelfde bestandje uitlees, dan blijft het bestandje voor een eeuwigheid bestaan.

Acties:
  • Beste antwoord
  • +1Henk 'm!

  • c-nan
  • Registratie: Juni 2008
  • Laatst online: 23:16
Een bestaande file:
code:
1
2
3
4
5
6
7
8
9
10
11
[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:
1
2
3
4
5
6
7
8
9
10
11
12
[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:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
[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:
1
2
3
4
5
6
7
8
9
10
11
12
[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:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
[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
  • Registratie: Juni 2001
  • Laatst online: 21:57

Creepy

Tactical Espionage Splatterer

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

"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have star problems" --Kevlin Henney


Anoniem: 1179574

Topicstarter
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
  • Registratie: Mei 2000
  • Laatst online: 22:00
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:
1
2
3
4
5
6
7
8
9
# 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]

Computers follow your orders, not your intentions.


  • Big Mama
  • Registratie: Mei 2000
  • Laatst online: 22:00
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.

Computers follow your orders, not your intentions.

Pagina: 1


Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee