Jim Meyering <[EMAIL PROTECTED]> writes: > 2) In any case, I'm not sure that such a change would be a good idea, > since it does subvert the semantics of --update. > But I'm open to arguments either way.
I suppose the new behavior could be added as a new option. That adds user complexity, but it may be inevitable given the current state of file timestamps. > + bool up_to_date = > + (x->preserve_timestamps && x->update > + ? MTIME_CMP_SEC (src_sb, dst_sb) <= 0 > + : x->update && MTIME_CMP (src_sb, dst_sb) <= 0); MTIME_CMP_SEC isn't defined in your patch, but I assume it compares only the seconds part of the time stamp, ignoring the nanoseconds. My first thought was that if HAVE_WORKING_UTIMES is set, then the code should compare seconds and microseconds, rather than ignoring the microseconds. After all, a working 'utimes' system call should be able to set the file timestamp to microsecond resolution. But this isn't quite right either. For example, the filesystem may support only millisecond resolution, even if 'utimes' supports a higher resolution. In that case, 'cp -p' will attempt to set the timestamp to microsecond resolution, but the microseconds part will be ignored. Here's a thought: we could extend --update to have an optional operand specifying a fuzz for timestamps. One simple would be to specify the time stamp resolution in Hz. For example: cp --update=1000000000 would have the current behavior, but cp --update=1000000 would ignore sub-microsecond parts of the source and destination time stamps, and cp --update=1 would ignore the fractional part of the time stamps. We wouldn't have to support all possible integer values for the update resolution. It'd be enough to do powers of 1000, at least at first. _______________________________________________ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
