Re: bug in du --time=atime

[William Brendling]

> >> Or (this may be better), how about an option that restores atime
> >> after the directory is read?
>
> 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.

OK. In that case there is probably a need for the option I suggested
earlier of omitting directories from the accumulated time.

> "stime"?  Do you mean st_atime?
Oops, yes.

>  But why would that be zero?

I simply report this as an observational fact on my (admittedly old)
RedHat 7.3 system. For directories, on first pass (with
fts_info==FTS_D) the value of st_atime is zero.

> The code is looking at (for example) end->fts_statp->st_mode soon after the 
> change you insert, here:

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

This code is not reached for directories on first pass. Both old and
new code return before this point if fts_info==FTS_D.

> 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?

Good point. Probably the simplest thing to do is to set the measured
size to zero at that point and continue, to accumulate the time.

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

Thanks. It applies the same hack as I was using anyway, but I should
use the standard interface. Moot anyway.