Re: bug in du --time=atime

[Paul Eggert]

William Brendling <address@hidden> writes:

> On 6/24/05, Paul Eggert <address@hidden> wrote:
>> A problem that I just noticed with the recent change to "du" is that
>> "du --time=atime" always reports the current time, for all entries.
>> This is because du reads each directory first, before it stats it,
>> which means the directory's last-accessed time is always the current
>> time.
>
> The following patch resolves this issue. For directories, the atime is
> collected during the first pass from FTS, prior to desending the
> directory tree.

Thanks for doing that.

>> Or (this may be better), how about an option that restores atime
>> after the directory is read?
>
> The new option --preserve-atime does this.

On second thought this might not be such a good idea, since it
clobbers any atime values set by other processes.  Perhaps we
should just leave this part out.

> I found that ent->fts_statp->stime

"stime"?  Do you mean st_atime?  But why would that be zero?  The code
is looking at (for example) end->fts_statp->st_mode soon after the
change you insert, here:

  if (skip
      || (!opt_count_all
          && ! S_ISDIR (sb->st_mode)
          && 1 < sb->st_nlink
          && ! hash_ins (sb->st_ino, sb->st_dev)))

If ent->fts_statp[0] is garbage, then why isn't S_ISDIR (sb->st_mode)
garbage in the pre-existing code?

Also -- and this may be another subject -- it seems to me that the
time code has a problem around here:

  /* If the file is being excluded or if it has already been counted
     via a hard link, then don't let it contribute to the sums.  */

With sizes it makes sense to skip hard links because you don't want to
count the same size twice.  But with time stamps you're not adding
things so does it really make sense to do that?  Wouldn't it be better
to count time stamps to hard links?

> The code would be neater if there is an equivalent of utimes that
> accepts "strut timespec" instead of "struct timeval".

utimens/futimens does that.  It's in lib/utimens.c.  But perhaps the
point is moot if we omit --preserve-atime.