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

2012-08-15 Thread Martin Steigerwald
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]

2012-08-15 Thread Martin Steigerwald
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]

2012-08-15 Thread Martin Steigerwald
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]

2012-08-15 Thread Martin Steigerwald
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]

2012-08-15 Thread James Youngman
Follow-up Comment #27, bug #12162 (project findutils): Could we discuss time handling in a _separate_ bug please? ___ Reply to this item at: ___ Message

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

2012-08-15 Thread Martin Steigerwald
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

2012-08-15 Thread Martin Steigerwald
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:

2012-08-15 Thread James Youngman
Update of bug #37106 (project findutils): Status:None => Invalid Assigned to:None => jay Open/Closed:Open => Closed ___

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

2012-08-15 Thread Martin Steigerwald
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:

2012-08-15 Thread Andreas Metzler
Follow-up Comment #1, bug #37106 (project findutils): Afaict find works as documented. Quoting find.1: SYNOPSIS find [-H] [-L] [-P] [-D debugopts] [-Olevel] [path...] [expression] i.e. -L needs to be listed before the path. cu andreas

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

2012-08-15 Thread Martin Steigerwald
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