Re: posix atime/ctime changes despite mtime being set

[Piotr Łobacz]

Paul I know this is the only difference, but posix format is forced to be used always by the format variable and it still differs…

I have run another test to write this $build_time variable to see if it differs as well...

Will takk to you later as it will finish.

BR

Piotr

---

Od: Użytkownik bug-tar-bounces+p.lobacz=welotec.com@gnu.org <bug-tar-bounces+p.lobacz=welotec.com@gnu.org> w imieniu użytkownika Piotr Łobacz <p.lobacz@welotec.com>
Wysłano: poniedziałek, lipca 31, 2023 5:25 PM
Do: Paul Eggert <eggert@cs.ucla.edu>; Sergey Poznyakoff <gray@gnu.org.ua>
DW: bug-tar@gnu.org <bug-tar@gnu.org>
Temat: Re: posix atime/ctime changes despite mtime being set

 

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.