#116 Dump 0.4b26 (at least on suse8.0) handles old dates wrong!!

open
dump (75)
5
2010-06-10
2005-09-01
Anonymous
No

Hi

Sorry but I have no new version of dump and the bug
is very eays to reproduce so if you want you can ...

dump 0.4b26 (using libext2fs 1.26 of 3-Feb-2002)
at least from suse8.0 has a date problem.
When the date is old (see below year 1905) dump always
will save this file to the media!

Arch: i386
glibc-2.2.5-177
kernel: 2.4.30

Example:

/etc/dumpdates before dump
/dev/hda18 0 Fri Aug 5 21:57:25 2005

Thu Sep 1 15:15:24 ART 2005
Dump date: Thu Sep 1 13:34:23 2005
Dumped from: Fri Aug 5 21:57:25 2005
Level 3 dump of /sh on bbmlap1:/dev/hda18
Label: Secphone
2 .
32705 ./dreamcast-linux-010605
....
17445
./dreamcast-linux-010605/usr/share/games/bsdgames/quiz/seq-hard
...

Here the output of ls -li
17445 -rw-r--r-- 1 bmeier bbm 872 Jun
8 1905
/sh/./dreamcast-linux-010605/usr/share/games/bsdgames/quiz/seq-hard

/etc/dumpdates after dump
/dev/hda18 3 Thu Sep 1 13:34:23 2005

Greetings

Beat

Discussion

  • Stelian Pop

    Stelian Pop - 2005-09-02
    • assigned_to: nobody --> stelian
     
  • Stelian Pop

    Stelian Pop - 2005-09-02

    Logged In: YES
    user_id=5513

    I think there is no bug here, but that your file had a ctime
    (change time) newer than your 0-level dump. The output of
    'ls -l' shows only the mtime (modification time), you will
    have to run the stat command on the file to see all the times.

    Dump will save a file if it has either the ctime *or* the
    mtime newer than the last incremental dump.

    With a newer version of dump you can also use the -m option
    to optimize the saving of those file whose inode has change
    but whose contents has not change (same mtime, newer ctime).
    Be sure to read the man page and the warnings contained
    inside for this option.

    Stelian.

     
  • Stelian Pop

    Stelian Pop - 2006-01-02
    • status: open --> closed-out-of-date
     
  • Stelian Pop

    Stelian Pop - 2006-01-02

    Logged In: YES
    user_id=5513

    Closing for lack of feedback.

     
  • Kieran Clancy

    Kieran Clancy - 2010-05-10

    Hi,

    I can actually verify this bug with the latest version of dump (dump-0.4b42).

    Dump (or e2fsprogs-libs) misreads the negative timestamp (pre-1970) as being far in the future, so the file gets backed up every time. I noticed it when an incremental backup was nearly a gigabyte larger than it should have been due to lots of files with ancient mtimes.

    I think the bug is in e2fsprogs-libs, where it defines the [amc]time fields as u32s. However, to be safe dump needs to cast the fields to be signed 32 bit integers.

    It's also worth noting that e2fsprogs-libs does not expose new ext4 fields like the extra bits for timestamp magnitude and nanoseconds, so this information is lost. The nanoseconds are arguably not very important, but the extra couple of bits for the timestamp (to allow dates beyond 2038) are significant (pun intended).

    To reproduce (as root):
    # dd if=/dev/zero of=test.img bs=1M count=5
    # losetup -f --show test.img
    # mkfs.ext3 /dev/loop0
    # mkdir test.mnt
    # mount /dev/loop0 test.mnt
    # touch -d '1 Jan 1969' test.mnt/pre1970
    # stat test.mnt/pre1970
    ...
    Access: 1969-01-01 00:00:00.000000000 +0930
    Modify: 1969-01-01 00:00:00.000000000 +0930
    Change: 2010-05-10 15:30:40.000000000 +0930
    # dump -f test.dump0 -0 -D test.dumpdates -u /dev/loop0
    # dump -f test.dump1 -1 -D test.dumpdates -u /dev/loop0
    # restore -t -f test.dump1
    ...
    12 ./pre1970
    (so it made it into the level 1 backup, which it should not have)
    # mkdir test.restore
    # restore -x -f ../test.dump0
    # stat pre1970
    Access: 2105-02-07 07:28:16.000000000 +1030
    Modify: 2105-02-07 07:28:16.000000000 +1030
    Change: 2010-05-10 16:20:24.122627031 +0930

    Notice how the atime and mtime have wrapped around and are now ridiculously far into the future, thanks to some combination of e2fsprogs-lib, dump and restore.

     
  • Stelian Pop

    Stelian Pop - 2010-06-10
    • status: closed-out-of-date --> open
     
  • Stelian Pop

    Stelian Pop - 2010-06-10

    Hmm, I cannot reproduce this on my system: I have a standard Ubuntu 10.04, and after restoring the file the times have not wrapped into the future.

    This is probably caused by some combination of 32 versus 64 bit / ext2fs / libc / kernel.

    The attached patch changes the data types in dump to signed instead of unsigned, this may fix the problem on your system (it doesn't change anything on mine). Could you please test it and report back ? Thanks.

     
  • Stelian Pop

    Stelian Pop - 2010-06-10

    Use a signed time_t for [acm]time

     

Log in to post a comment.