Re: [bug #46815] problem when testing file size

than 21. So or so, the behaviour of find with size and time comparisions (other bug is open about it) is user unfriendly and unintuitive. So if thats a standard, then I´d say the standard is broke. -- Martin Steigerwald | Consultant / Trainer teamix GmbH Südwestpark 43 90449 Nürnberg Tel.: +49

Re: [bug #46815] problem when testing file size

well. > Thus said, a new option could fix all the things for the user, but > I'm convinced that it could all be done with -size, too. I also suggest to coordinate this with any adaption for the time comparision switches for some consitency, at least in case you decide for eq, lt

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

Follow-up Comment #25, bug #12162 (project findutils): Updated time results for consistency comparison: ms@mango:/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

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

Follow-up Comment #24, bug #12162 (project findutils): Forget the time results. touch sets access and modification time, not status change time. I test again with mtime. ___ Reply to this item at: _

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

Follow-up Comment #23, bug #12162 (project findutils): I have: mango:/tmp# find -name "nullen*" -printf "%p %sn" | sort ./nullen0999 1022976 ./nullen1000 1024000 ./nullen1001 1025024 ./nullen1024 1048576 ./nullen1025 1049600 ./nullen2047 2096128 ./nullen2048 2097152 ./nullen2049 2098176 Yet whil

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

Follow-up Comment #28, bug #12162 (project findutils): James, sure, would get to convoluted here otherwise. I reported the time stuff as bug #37110 find: alternative time handling. I think its important to keep times somewhere in mind in order to be able to find a solution that work consistently b

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

Follow-up Comment #26, bug #12162 (project findutils): -[a|c|m]time eq 1d makes no sense with nanosecond precision cause it hits extremely rarely. I´d skip -eq for times. Searching exact filesizes make more sense. -[a|c|n]time eq "exact absolute time spec" makes more sense, cause search for an ex

[bug #37110] find: alternative time handling

URL: Summary: find: alternative time handling Project: findutils Submitted by: martin21 Submitted on: Mi 15 Aug 2012 17:30:07 GMT Category: find Severity: 3 - Normal

[bug #37106] find: option -L only works when no search path is given:

Follow-up Comment #2, bug #37106 (project findutils): Hmmm, agreed. As with -H and -P. And as clarified in: The -H, -L and -P options control the treatment of sym- bolic links. Command-line arguments following these are taken to be names of files or directories to be exa

[bug #37106] find: option -L only works when no search path is given:

URL: Summary: find: option -L only works when no search path is given: Project: findutils Submitted by: msteamix Submitted on: Mi 15 Aug 2012 12:34:50 GMT Category: find