Jeg kæmper for at vikle mig rundt hvorfor find fortolker filen ændring gange som den gør. Specifikt forstår jeg ikke hvorfor -mtime +1 ikke viser filer under 48 timer gamle.

Som et eksempel på en test Jeg oprettede tre testfiler med forskellige ændrede datoer: 

[root@foobox findtest]# ls -l total 0 -rw-r--r-- 1 root root 0 Sep 25 08:44 foo1 -rw-r--r-- 1 root root 0 Sep 24 08:14 foo2 -rw-r--r-- 1 root root 0 Sep 23 08:14 foo3

Jeg løb derefter find med -mtime +1 -kontakten og fik følgende output: 

[root@foobox findtest]# find -mtime +1 ./foo3

Jeg kørte derefter find med -mmin +1440 og fik følgende output: 

[root@foobox findtest]# find -mmin +1440 ./foo3 ./foo2

I henhold til mandsiden for find, forstår jeg, at dette er forventet adfærd: 

 -mtime n File’s data was last modified n*24 hours ago. See the comments for -atime to understand how rounding affects the interpretation of file modification times. -atime n File was last accessed n*24 hours ago. When find figures out how many 24-hour periods ago the file was last accessed, any fractional part is ignored, so to match -atime +1, a file has to have been accessed at least two days ago.

Dette giver dog stadig ikke mening for mig. Så hvis en fil er 1 dag, 23 timer, 59 minutter og 59 sekunder gammel, ignorerer find -mtime +1 alt det og behandler det bare som det er 1 dag, 0 timer, 0 minutter , og 0 sekunder gammel? I hvilket tilfælde er den ikke teknisk ældre den 1 dag og ignoreret?

Beregner … ikke …

Kommentarer

  • Først syntes det også sjovt for mig, men når man tænker på, at det måler en filalder på hele dage, så gør det nøjagtigt hvad du ‘ forventer. Det vandt ‘ ikke at give filer svarende til 1 dag gamle. En fil, der er int (1,99) dage gammel, er ikke > 1.
  • Tænk på, hvordan mennesker behandler alderen i daglig tale. Hvis nogen er 79,9 år, siger du, at de er 79 år. Så hvis du leder efter et menneske over 79 år, så leder du efter et menneske, der er > 79.99999 år gammelt, dvs. > = 80 år gammel. Folk ser på alderen som heltal og runder den ned og ser hver alder som et interval.

Svar

Nå , det enkle svar er, antager jeg, at din findimplementering følger POSIX / SuS-standarden, der siger, at den skal opføre sig på denne måde. Citat fra SUSv4 / IEEE Std 1003.1, 2013-udgave, “find” :

-mtime n
Primæren skal evalueres som sand, hvis filændringstiden trukket
fra initialiseringstiden divideret med 86400 (med en hvilken som helst rest kasseret) er n.

(Andetsteds i dokumentet forklares det, at n faktisk kan være +n, og betydningen af det som “større end”).

Hvorfor standarden siger, at den skal opføre sig sådan – ja, jeg gætter længe på, at en programmør var doven eller ikke tænkte over det, og bare skrev C kode (current_time - file_time) / 86400. Heltals aritmetik kasserer resten. Scripts startede afhængigt af den adfærd, og derfor blev den standardiseret.

Specifikationen ville også være bærbar til et hypotetisk system, der kun gemte en ændringsdato (ikke tid). Jeg ved ikke, om et sådant system har eksisteret.

Kommentarer

  • find var klart designet til kun at udføre oprydningsjob.

Svar

Argumentet til -mtime fortolkes som antallet af hele dage i filens alder. -mtime +n betyder strengt større end , -mtime -n betyder strengt mindre end.

Bemærk at du med Bash kan gøre det mere intuitive: 

$ find . -mmin +$((60*24)) $ find . -mmin -$((60*24))

for at finde filer, der er ældre og nyere end henholdsvis 24 timer.

(Det er også lettere end at skrive et brøkargument til -mtime, når du vil have opløsning i timer eller minutter.)

Kommentarer

  • For at liste disse filer (kun almindelig) med læselige størrelser og i chr onologisk rækkefølge skal du gøre $ find . -type f -mmin -$((60*24)) -exec ls -halt {} +
  • Dette vil også have den samme effekt, fordi begge disse kommandoer sammen stadig vil savne filerne inden for det minutvindue for 24 timer siden .
  • $(()) er almindelig shell-aritmetisk syntaks, den ‘ er ikke specifik for Bash, jf. pubs.opengroup.org/onlinepubs/009695399/utilities/…
  • @JosipRodin No , ikke nødvendigvis sandt! This chapter describes the syntax of that command language as it is used by the sh utility and [...]. Da Bash er en ” udvidet ” SH, understøtter den denne syntaks, men nogle andre skaller don ‘ t, f.eks csh / tcsh.
  • @ t0r0X min pointe var, at det ‘ ikke er en bashisme, snarere fungerer det i bindestreg og zsh og hvad der ellers fungerer som en konventionel /bin/sh.

Svar

Fraktionerede 24-timers perioder er afkortet! Det betyder, at “find -mtime +1” siger at matche filer, der blev ændret for to eller flere dage siden. 

find . -mtime +0 # find files modified greater than 24 hours ago find . -mtime 0 # find files modified between now and 1 day ago # (i.e., in the past 24 hours only) find . -mtime -1 # find files modified less than 1 day ago (SAME AS -mtime 0) find . -mtime 1 # find files modified between 24 and 48 hours ago find . -mtime +1 # find files modified more than 48 hours ago

Følgende fungerer muligvis kun på GNU? 

find . -mmin +5 -mmin -10 # find files modified between # 6 and 9 minutes ago find / -mmin -10 # modified less than 10 minutes ago

Kommentarer

  • Tak, jeg prøvede at finde ud af hvorfor -mtime X var anderledes end -mtime + X
  • Jeg regner med at + X betyder shorts til (X + 1, X + 2, X + 3, …). 🙂
  • links til alle kildedokumenterne forvirrer det enkle svar. Eksempler betyder noget. dens gode dokumentation. Lad os gøre flere af dem! Jeg kan godt lide dette svar

Svar

-mtime N betyder filer, hvis alder A i dage opfylder N ≤ A < N + 1. Med andre ord vælger -mtime N filer, der sidst blev ændret mellem N og N + for +1 dage siden.

-mtime -N betyder filer hvis alder A opfylder A < N dvs. filer ændret for mindre end N dage siden. Mindre intuitivt betyder -mtime +N filer hvis alder A tilfredsstiller N +1 ≤ A , dvs. filer ændret for mindst N for +1 dage siden.

F.eks. vælger -mtime 1 filer, der blev ændret for 1 til 2 dage siden. -mtime +1 vælger filer, der blev ændret for mindst to dage siden. For at få filer ændret for mindst 1 dag siden skal du bruge -mtime +0.

Beskrivelsen “blev sidst ændret n * 24 timer siden” er kun en tilnærmelse og ikke en meget klar.

Hvis du finder disse regler svære at huske, skal du bruge en referencefil i stedet. 

touch -d "1 day ago" cutoff find . -newer cutoff

(Syntaksen “ For 1 dag siden ”kræver GNU touch.)

Kommentarer

  • Dejlig forklaring, de første 3 afsnit skal føjes til dokumentationen til find!

Svar

Så hvis en fil er 1 dag, 23 timer, 59 minutter og 59 sekunder gammel, find -mtime +1 ignorerer alt det og behandler det bare som det er 1 dag , 0 timer, 0 minutter og 0 sekunder gamle?

Ja. Ligesom man find siger, “enhver brøkdel ignoreres “. Hvis du deler” 1 dag, 23 timer, 59 minutter og 59 sekunder “gennem” 24 timer “, får du muligvis 1.9999, men t han .9999-del fjernes derefter, og pludselig er filen kun 1 dag gammel.

Svar

Brug -mmin, -amin osv. for at få nøjagtige resultater

Kommentarer

  • -?min argumenter fungerer nøjagtigt som -?time argumenter undtagen med minutter i stedet for dage. De er heller ikke ‘ t “nøjagtige.

Svar

Hvis du vil have nøjagtigt 48 timer gamle filer, ikke 2 dage, skal du tilføje --daystart i din find -kommando. Dette hjælper dig. 

find . type -f -daystart -mtime +1

Kommentarer

  • Nej, først ‘ s -daystart (en GNU-udvidelse), ikke --daystart. Derefter betyder -daystart bare at sammenligne tidspunkter med begyndelsen af i dag i stedet for det aktuelle tidspunkt, så --daystart -mtime +1 ville rapportere filer, der blev ændret mere det 48 timer / 2 timer før begyndelsen af i dag, så normalt er filer, der blev ændret strengt før i går.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *