Dear Mr. Hoots,
Unfortunately, the correct behavior depends on how the GNU tar 1.13.x
format (--format=gnu) defines the meaning of 95-bit binary timestamps,
which is not stated in the current GNU tar manual.
If binary timestamps are not allowed or interpreted as a pure count
of seconds up to the extremely far future, then fractions of seconds
cannot be used. But if they are interpreted as a fixed format binary
number where a certain number of the least significant bits represent
fractions of the second, many fractional values could be stored, even
if the tar version you tested doesn't use this. For example,
interpreting 95-bit binary timestamps as 63 bits for the seconds and
32 bits for a binary multiple of 2**(-32) seconds (like in NTP), all
post-1970 timestamps compatible with int64_t time_t can be stored
with a precision of 0.25ns .
However the PAX format can represent any timestamps precision via
pax attributes.
Another issue in your test is that tar did not store or restore the
access and change timestamps, leaving those equal to the time when
the restore was done.
On 17/02/2026 12:59, [email protected] wrote:
Dear all,
please let me know if I am wrong here.
I am trying to compress and extract a tar archive while trying to
maintain the modification timestamp in nanoseconds. The files are from
a make system that if the timestamps are not correctly restored will
cause a rebuild of some very time consuming components - that is the
gist of it.
The simple test scenario below shows where I think the timestamp
accuracy appears to get lost
1. touch test.txt
2. stat test.txt
File: test.txt
Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: 8,1Inode: 24520316 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ oliver) Gid: ( 1000/
oliver)
Access: 2026-02-17 11:39:28.366000000 +0000
Modify: 2026-02-17 11:39:28.366000000 +0000
Change: 2026-02-17 11:39:28.366000000 +0000
Birth: 2026-02-17 11:25:59.010000000 +0000
3. tar --full-time --utc --format=gnu --verbose -cf test.tar test.txt
-rw-r--r-- oliver/oliver 0 2026-02-17 11:39:28.366 test.txt
4. tar --full-time --utc --format=gnu --verbose -tf test.tar
-rw-r--r-- oliver/oliver 0 2026-02-17 11:39:28 test.txt
5. mkdir -p test && tar --full-time --utc --format=gnu --verbose -xf
test.tar -C test
-rw-r--r-- oliver/oliver 0 2026-02-17 11:39:28 test.txt
6. stat test.txt test/test.txt
File: test.txt
Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: 8,1Inode: 24520316 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ oliver) Gid: ( 1000/
oliver)
Access: 2026-02-17 11:39:28.366000000 +0000
Modify: 2026-02-17 11:39:28.366000000 +0000
Change: 2026-02-17 11:39:28.366000000 +0000
Birth: 2026-02-17 11:25:59.010000000 +0000
File: test/test.txt
Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: 8,1Inode: 24649659 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ oliver) Gid: ( 1000/
oliver)
Access: 2026-02-17 11:44:08.410000000 +0000
Modify: 2026-02-17 11:39:28.000000000 +0000
Change: 2026-02-17 11:44:08.410000000 +0000
Birth: 2026-02-17 11:44:08.410000000 +0000
It appears that at step 3 the timestamp in nanoseconds is not stored
in the archive test.tar and from this moment onwards is lost.
My system is Debian GNU/Linux 12 (bookworm), running on and Intel PC
and the filesystem is ext4.
uname -a shows
Linux work-vm 6.1.0-42-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.159-1
(2025-12-30) x86_64 GNU/Linux
Is there anything that I do wrong or is this a bug I stumbled upon?
- perhaps a configuration issue?
Thank you very much in advance looking into this.
Kind regards,
Oliver
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
