Re: [PATCH] cp --update --preserve

[Paul Eggert]

Jim Meyering <address@hidden> 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.