Date: Mon, 21 Jun 2004 16:31:57 -0700 From: David Schultz <das@FreeBSD.ORG> To: David Malone <dwmalone@maths.tcd.ie> Cc: Scott Mitchell <scott+freebsd@fishballoon.org> Subject: Re: /bin/ls sorting bug? Message-ID: <20040621233157.GA1072@VARK.homeunix.com> In-Reply-To: <200406210910.aa18808@salmon.maths.tcd.ie> References: <20040621054406.GA927@VARK.homeunix.com> <200406210910.aa18808@salmon.maths.tcd.ie>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jun 21, 2004, David Malone wrote: > > Sorting on nanoseconds too is likely to be more confusing than > > useful. Even if we use one of the precious few option letters ls > > doesn't use already to add a nanosecond display, most people won't > > know about it because they don't care about nanoseconds. They > > might care when they notice---as you did---that the sort order > > isn't what they expected. > > At the moment in FreeBSD the nanoseconds field is always zero, > unless you twiddle vfs.timestamp_precision, so it would make no > difference to joe user. For people that do set vfs.timestamp_precision, > it would be nice if ls did the right thing (for example, test already > compares the nanoseconds field, after someone submitted a PR because > it didn't). > > > Is the point of sorting on nanoseconds to totally order the files > > based on modification time? > > Depending on the clock resolution (which is partially determined > by vfs.timestamp_precision and partially determined by the actual > clock resolution), it may not be enough to totally order the files. Yep, that was going to be my next point. I don't think this is particularly useful, or necessarily even a good idea, but AFAIK POSIX doesn't say anything about using a consistent timer resolution when processing file timestamps, so don't let that stop you... Now let's re-raise the *original* bikeshed of adding nanosecond support to sleep!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040621233157.GA1072>