Re: posix atime/ctime changes despite mtime being set

[Piotr Łobacz]

In addition.

Wysyłane z aplikacji Outlook dla systemu iOS

---

Od: Paul Eggert <eggert@cs.ucla.edu>
Wysłane: Monday, July 31, 2023 5:24:15 PM
Do: Sergey Poznyakoff <gray@gnu.org.ua>
DW: bug-tar@gnu.org <bug-tar@gnu.org>; Piotr Łobacz <p.lobacz@welotec.com>
Temat: Re: posix atime/ctime changes despite mtime being set

 

On 2023-07-31 07:54, Sergey Poznyakoff wrote:
> is this used in addition to --mtime --clamp-mtime options or instead
> of them?

What I see at
<https://eur04.safelinks.protection.outlook.com/?url="">>
are differences like the following. One archive has this:

 
-rw-r--r--···0········0········0·····8418·2016-02-09·06:19:51.000000·./usr/src/debug/avahi/0.8-r0/avahi-autoipd/iface-linux.c

whereas the other one has this:

 
-rw-r--r--···0········0········0·····8418·2016-02-09·06:19:51.127711·./usr/src/debug/avahi/0.8-r0/avahi-autoipd/iface-linux.c

That is, the only difference is in the subseconds part of the timestamp,
where the first archive says ".000000" whereas the second one says
".127711". This can happen if one generates two tarballs, one with the
default gnu format or the use tar format (both of which lack subsecond
resolution) and the other with posix format (which has subseconds).

To fix this sort of thing with current tar, it's a hassle: one must set
each source file's timestamp to an integer multiple of seconds, in
addition to the --mtime="$SOURCE_EPOCH" --clamp-mtime business. It might
be helpful to add to GNU Tar an option (--timestamp-resolution=1, say,
or perhaps it should be a --pax-option suboption), that causes 'tar' to
generate only the stated timestamp resolution.