Debian Bug report logs - #1053535
Add support for timestamps with nanoseconds [patch]

Reply or subscribe to this bug.

Display info messages

Message #5 received at [email protected] (full text, mbox, reply):

From: markus <[email protected]>

To: [email protected]

Subject: Add support for timestamps with nanoseconds [patch]

Date: Thu, 5 Oct 2023 21:51:40 +0200

[Message part 1 (text/plain, inline)]

Package: dump
Version: 0.4b47-4

Hello,

here is a patch to add support for timestamps with nanoseconds for dump and restore.

For this struct dinode in compat/include/bsdcompat.h is extended with nanoseconds timedata.

As a consequence dumpfiles (or -tapes) from previous versions of dump are not compatible with the new version of restore.

In order to prevent a version mismatch it would be desireable to have a version information at the beginning of dumpfiles. I did not manage to find the code locations where dump begins to write resp. where restore begins to read. Maybe someone else copes with this.

Markus

[dump_0.4b47.orig.tar.gz (application/octet-stream, attachment)]

[dump_0.4b47-4+ema1_amd64.changes (application/octet-stream, attachment)]

[dump_0.4b47-4+ema1.debian.tar.xz (application/x-xz, attachment)]

[dump_0.4b47-4+ema1.dsc (application/octet-stream, attachment)]

[timestamps-with-nanoseconds (application/octet-stream, attachment)]

[Tneu.dump (application/octet-stream, attachment)]

[Tneu.txz (application/x-xz-compressed-tar, attachment)]

Message #10 received at [email protected] (full text, mbox, reply):

From: Alexander Zangerl <[email protected]>

To: markus <[email protected]>, [email protected]

Cc: [email protected]

Subject: Re: Bug#1053535: Add support for timestamps with nanoseconds [patch]

Date: Fri, 06 Oct 2023 17:28:48 +0200

[Message part 1 (text/plain, inline)]

severity 1053535 wishlist
tags 1053535 + moreinfo
thanks

On Thu, 05 Oct 2023 21:51:40 +0200, markus writes:
>here is a patch to add support for timestamps with nanoseconds for dump
>and restore
...
>As a consequence dumpfiles (or -tapes) from previous versions
>of dump are not compatible with the new version of restore.

i'm not at all convinced that this is a useful change, in particular
in a backup/restore tool.

please provide more information as to what benefits this change is
expected to provide, and how those benefits are supposed to outweight
the massive downside of complete incompatibility with existing backups.

regards
az


-- 
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + https://snafu.priv.at/
"Mary had a little key,/She kept it in escrow/And everything that Mary
sent/The Feds were sure to know." -- Sam Simpson

[signature.asc (application/pgp-signature, inline)]

Message #19 received at [email protected] (full text, mbox, reply):

From: markus <[email protected]>

To: [email protected]

Subject: Re: Bug#1053535: Add support for timestamps with nanoseconds [patch]

Date: Thu, 12 Oct 2023 15:37:34 +0200

Hello,

> i'm not at all convinced that this is a useful change, in particular
> in a backup/restore tool.

A restore tool should, as its name says, restore the backup as most pristine as possible. Currently dump/restore (on linux) restores timestamps only with seconds, dropping micro- or nanoseconds.

> please provide more information as to what benefits this change is
> expected to provide,

For more than a decade linux kernels and ext2/3/4 filesystems support timestamps with nanoseconds. Most userland utilities have been updated to use it. dump/restore is overdue. It is a severe deficit loosing a part of time information when restoring a backup. I believe nowadays most expect that a backup tool uses all facilities the underlying system supports.

> and how those benefits are supposed to outweight
> the massive downside of complete incompatibility with existing backups.

Incompatibility with existing backups is an issue only, if backups are archived. Usually backups are overwritten regularly. (In my case every two months.)

In order to prevent a mismatch a version information at the beginng of a dumpfile (or tape) would be useful. I did not manage to find the code locations where dump begins to write resp. where restore begins to read.

I have found restore contains some code to convert "old headers". I could not figure out, what this means. The code for opening and reading a dumpfile is rather complicated and not well documented.

Please note the patch does not introduce a "complete incompatibility". I did some tests with mixed combinations with old/new dumps and old/new restores. Directories and files where restored correctly but with erroneous timestamps.

Please note there already is a mismatch between sizeof(dinode) and sizeof(ext2_inode) before applying the patch. assert(sizeof(dinode_old) <= sizeof(ext2_inode)) failes. See compat/include/bsdcompat.h and dump/traverse.c.

I have sent my patch in in order to share it with the community.
May be someone else picks it up and adds version information to the dumpfile.

Markus

Message #24 received at [email protected] (full text, mbox, reply):

From: Alexander Zangerl <[email protected]>

To: [email protected]

Cc: [email protected]

Subject: i'm not changing this

Date: Tue, 26 Dec 2023 11:33:29 +1000

[Message part 1 (text/plain, inline)]

tags 1053535 + wontfix
thanks

after further consideration i've decided taht i'm not going
to apply this patch: i do not want to change the on-disk format of dumps
for the minimal benefit of archiving files with
nanosecond timestamps.


-- 
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + https://snafu.priv.at/
Only two things are infinite, the universe and human stupidity, 
and I'm not sure about the former.  -- Albert Einstein

[signature.asc (application/pgp-signature, inline)]

Send a report that this bug log contains spam.