William Brendling <[EMAIL PROTECTED]> writes: > On 6/24/05, Paul Eggert <[EMAIL PROTECTED]> 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. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils