On 2004-06-19 at 21:35:45 Scott Mitchell wrote: > Sure (added -i to make it easier to see what's going on here):
> (505) tuatara:/tmp/foo $ ls -iltT
> total 0
> 35 -rw-rw-r-- 1 scott wheel 0 19 Jun 17:48:40 2004 c
> 11 -rw-rw-r-- 7 scott wheel 0 19 Jun 17:13:36 2004 b
> 11 -rw-rw-r-- 7 scott wheel 0 19 Jun 17:13:36 2004 d
> 11 -rw-rw-r-- 7 scott wheel 0 19 Jun 17:13:36 2004 e
> 11 -rw-rw-r-- 7 scott wheel 0 19 Jun 17:13:36 2004 f
> 11 -rw-rw-r-- 7 scott wheel 0 19 Jun 17:13:36 2004 g
> 11 -rw-rw-r-- 7 scott wheel 0 19 Jun 17:13:36 2004 h
> 41 -rw-rw-r-- 1 scott wheel 0 19 Jun 17:13:36 2004 i
> 51 -rw-rw-r-- 1 scott wheel 0 19 Jun 17:13:36 2004 j
> 11 -rw-rw-r-- 7 scott wheel 0 19 Jun 17:13:36 2004 a
> 52 -rw-rw-r-- 1 scott wheel 0 19 Jun 17:13:36 2004 k
> Most of those files (a,b,d,e,f,g,h) are hard-linked to each other - so they
> definitely share the same timestamp. i,j,k were created with 'touch -r a i
> j k', so they should also have the same time. c is different to make sure
> I didn't break the sort order when files *did* have different times.
Looking through ls source shows that the sorting is done by passing a
comparison function to fts_open(3). In the case of sorting by
modification time, the *only* comparison made is of the mtime fields:
int
modcmp(const FTSENT *a, const FTSENT *b)
{
return (b->fts_statp->st_mtime - a->fts_statp->st_mtime);
}
So, if these fields for two different files are exactly the same, the
resulting sorted list will have an undefined order for all other
fields. And AFAICS, there's no way to tell ls: "first sort on time,
then on filename, then on size", etc. This would make a nice addition
though. :)
Note also that the fts(3) functions use qsort(3), which isn't stable,
so you will not always get the order in which these entries are listed
in the directory itself.
pgpptkEJqFrSc.pgp
Description: PGP signature
