[bug #12162] Enhancement req: finding files less than 2Gb in size [needs community feedback]

[Martin Steigerwald]

Follow-up Comment #25, bug #12162 (project findutils):

Updated time results for consistency comparison:

address@hidden:/tmp/find-times> ls -l                                     
insgesamt 0
-rw-rw-r-- 1 ms teamix 0 Aug 14 18:11 lessthan1dayago
-rw-rw-r-- 1 ms teamix 0 Aug 13 18:12 lessthan2daysago
-rw-rw-r-- 1 ms teamix 0 Aug 12 18:12 lessthan3daysago
-rw-rw-r-- 1 ms teamix 0 Aug 14 16:11 morethan1dayago
-rw-rw-r-- 1 ms teamix 0 Aug 13 16:11 morethan2daysago
-rw-rw-r-- 1 ms teamix 0 Aug 12 16:11 morethan3daysago
address@hidden:/tmp/find-times> date
Mi 15. Aug 16:29:51 CEST 2012
address@hidden:/tmp/find-times> find -mtime +1  -printf "%pt %tn" | sort
./lessthan3daysago       Sun Aug 12 18:12:10.0626806028 2012
./morethan2daysago       Mon Aug 13 16:11:42.0727680142 2012
./morethan3daysago       Sun Aug 12 16:11:50.0715653807 2012

As predicted -mtime +1 translated to more than two days ago.

address@hidden:/tmp/find-times> find -mtime +3  -printf "%pt %tn" | sort

+3 translates to more than 4 days ago, thus no results

address@hidden:/tmp/find-times> find -mtime +2  -printf "%pt %tn" | sort
./morethan3daysago       Sun Aug 12 16:11:50.0715653807 2012

And +2 to more than 3 days ago.

Yet with -time it seems to be the other way around:

address@hidden:/tmp/find-times> find -mtime -2  -printf "%pt %tn" | sort
./lessthan1dayago        Tue Aug 14 18:11:33.0444291877 2012
./lessthan2daysago       Mon Aug 13 18:12:00.0302854716 2012
./morethan1dayago        Tue Aug 14 16:11:23.0258103147 2012
.        Wed Aug 15 16:12:10.0625203012 2012

-2 translates to less than 2 days ago (as I actually wrote before)

address@hidden:/tmp/find-times> find -mtime -1  -printf "%pt %tn" | sort
./lessthan1dayago        Tue Aug 14 18:11:33.0444291877 2012
.        Wed Aug 15 16:12:10.0625203012 2012

-1 to less than one day ago.

Thus we have:

-mtime -1: less than one day
-mtime 1: one day, 24-48 or <48 hours
-mtime +1: more than two days!

And:

-size -1M: 0 MBytes = 0 bytes
-size -2M: less or equal than 1 MiB!
-size +1M: more than 1 MiB

I'd suggest:

-size lt 1M: less than one MiB (< 1048576 bytes, 1048575 matches 1048576 does
not match)
-size lte 1M: less than or equal one MiB (<= 1048576 bytes)
-size gt 1M: more than one MiB (> 1048576 bytes)
-size gte 1M: more or equal than one MiB (>= 1048576 bytes)
-size eq 1M: exactly one MiB (=1048576 bytes)

And for completeness for times as well:

-mtime lt 1d: less than one day (00:00:00 to 23:59:59.9999999999999, short <
24:00:00)
-mtime lte 1d: less or equal one day (00:00:00 to 24:00:00)
-mtime gt 1d: more than one day (24:00:00.0000000000001, short >24:00:00 to
anything)
-mtime gte 1d: more or equal one day (24:00:00 to anything)
maybe -mtime eq 1d: exactly one day (24:00:00.000000000000)

Old semantic for -mtime 1 can be more clearly expressed by:

-mtime gte 1d -and -mtime lt 2d


Advantages:
1) a lot more intuitive to human beings

2) distinction between < and <= as well as > and >=

3) compatible with old scripts, cause old behavior can be kept (I actually
teach the -[a|c|m]time wierdness since quite some time)

4) no conflict with input/output redirection

5) different units possible for times as well (d = days, h = hours, m=minutes,
M=months, Y=years and such or even have it verbose to reduce ambiquity)

I am not so sure about the usefulness / semantics of the "eq" case, especially
for times. For sizes it might make more sense. But then exactly matching a
time could be useful.

I happily put the time stuff in an extra report and link to it from here. But
I thought the comparison with time handling makes the inconsistency in find
behaviour from the viewpoint of human beings even more obvious.

The current handling of -size / -[a|c|m]time IMHO is well suited for machines
(integer math with any, even big units), but not for humans.

What do you think?

Martin

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?12162>

_______________________________________________
  Nachricht gesendet von/durch Savannah
  http://savannah.gnu.org/