Bug#665387: dar: Still getting error: Dates of file's data are not increasing when database's archive number grows
March 23rd, 2012 - 12:50 pm ET by Graham Cobb | Report spam
Package: dar
Version: 2.4.2-1
Severity: important
This is a followup to 637997, which is now archived so opening a new bug.
My earlier assumption that this problem was caused by the bug fixed upstream
in dar 2.4 is incorrect. I have now installed dar 2.4.2.1 (Wheezy) and this
bug is still occuring. In fact it is now much worse because it does not just
affect archives created with old versions of dar but prevents all differential
backups being taken, breaking my whole backup strategy. I will have to
downgrade to an earlier version of dar.
I created a full archive and inserted it into dar_manager. A few days later
I created an incremental archive of the same files but when I try to insert
it into dar_manager I get the following errors:
[Start of errors]
Dates of file's data are not increasing when database's archive number grows.
Concerned file is: usr/share/mime/packages/palapeli-mimetypes.xml
Dates are not increasing for all files when database's archive number grows,
working with this database may lead to improper file's restored version.
Please reorder the archive within the database in the way that the older is
the first archive and so on up to the most recent archive being the last of
the database
Dates of file's data are not increasing when database's archive number grows.
Concerned file is: usr/share/mime/packages/okteta.xml
Dates of file's data are not increasing when database's archive number grows.
Concerned file is: usr/share/doc/kde/HTML/en/ksystemlog/filter-process.png
Dates of file's data are not increasing when database's archive number grows.
Concerned file is: usr/share/doc/kde/HTML/en/ksystemlog/main-screen.png
[... lots more similar messages ...]
Dates of file's data are not increasing when database's archive number grows.
Concerned file is: usr/bin/wcgrep
Dates of file's data are not increasing when database's archive number grows.
Concerned file is: usr/include/kprofilemethod.h
Dates of file's data are not increasing when database's archive number grows.
Concerned file is: usr/lib/libgd.so.2.0.0
Error met while processing operation: Some files do not follow chronological
order when archive index increases withing the database, this can lead
dar_manager to restored a wrong version of these files
Some files do not follow chronological order when archive index increases
withing the database, this can lead dar_manager to restored a wrong version of
these files
DARsystem: Warning: Adding DARsystemDiff01 to DARsystemDataBase failed.
[End of errors]
I note that between the two archives I did do a large "aptitude upgrade",
upgrading many packages. And I note that all the files complained about are
files from packages. Most of them are .png files but there are others
(including many from /usr/bin).
Looking at the "dar -l" output from the two archives for one of the files I
note that the earlier archive shows:
[Saved] [ 52%][ ] -rwxr-xr-x root root 2387 Wed Jan 19 22:07:51 2011 usr/bin/wcgrep
And the later archive shows:
[Saved] [ 52%][ ] -rwxr-xr-x root root 2387 Tue Jan 29 09:18:04 2008 usr/bin/wcgrep
So, the problem appears to be because the later archive has an earlier mtime
for the file (year 2008 instead of 2011). However, I believe it has a later
ctime so dar appears to be using the wrong time field in its checking.
I can reproduce the bug using the following script, in a clean directory:
#!/bin/sh
mkdir a
echo "First version" >a/test
tar cf test.earlier.tar a
sleep 60
echo "Second version" >a/test
tar cf test.later.tar a
rm -rf a
tar xf test.later.tar
ls -l a/test
ls -lc a/test
ls -la a/test
dar -c first -g a
tar xf test.earlier.tar
ls -l a/test
ls -lc a/test
ls -la a/test
dar -c second -g a -A first
dar_manager -C testdb
dar_manager -B testdb -A first
dar_manager -B testdb -A second
This completely breaks dar's incremental backup feature.
Debian Release: wheezy/sid
APT prefers testing
APT policy: (990, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_IE@euro, LC_CTYPE=en_IE@euro (charmap=ISO-8859-15) (ignored: LC_ALL set to en_IE@euro)
Shell: /bin/sh linked to /bin/bash
Versions of packages dar depends on:
ii libattr1 1:2.4.46-5
ii libbz2-1.0 1.0.6-1
ii libc6 2.13-27
ii libdar64-5 2.4.2-1
ii libgcc1 1:4.6.3-1
ii libgcrypt11 1.5.0-3
ii libgpg-error0 1.10-3
ii liblzo2-2 2.06-1
ii libstdc++6 4.6.3-1
ii zlib1g 1:1.2.6.dfsg-2
dar recommends no packages.
Versions of packages dar suggests:
pn dar-docs 2.4.2-1
pn par2 <none>
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Version: 2.4.2-1
Severity: important
This is a followup to 637997, which is now archived so opening a new bug.
My earlier assumption that this problem was caused by the bug fixed upstream
in dar 2.4 is incorrect. I have now installed dar 2.4.2.1 (Wheezy) and this
bug is still occuring. In fact it is now much worse because it does not just
affect archives created with old versions of dar but prevents all differential
backups being taken, breaking my whole backup strategy. I will have to
downgrade to an earlier version of dar.
I created a full archive and inserted it into dar_manager. A few days later
I created an incremental archive of the same files but when I try to insert
it into dar_manager I get the following errors:
[Start of errors]
Dates of file's data are not increasing when database's archive number grows.
Concerned file is: usr/share/mime/packages/palapeli-mimetypes.xml
Dates are not increasing for all files when database's archive number grows,
working with this database may lead to improper file's restored version.
Please reorder the archive within the database in the way that the older is
the first archive and so on up to the most recent archive being the last of
the database
Dates of file's data are not increasing when database's archive number grows.
Concerned file is: usr/share/mime/packages/okteta.xml
Dates of file's data are not increasing when database's archive number grows.
Concerned file is: usr/share/doc/kde/HTML/en/ksystemlog/filter-process.png
Dates of file's data are not increasing when database's archive number grows.
Concerned file is: usr/share/doc/kde/HTML/en/ksystemlog/main-screen.png
[... lots more similar messages ...]
Dates of file's data are not increasing when database's archive number grows.
Concerned file is: usr/bin/wcgrep
Dates of file's data are not increasing when database's archive number grows.
Concerned file is: usr/include/kprofilemethod.h
Dates of file's data are not increasing when database's archive number grows.
Concerned file is: usr/lib/libgd.so.2.0.0
Error met while processing operation: Some files do not follow chronological
order when archive index increases withing the database, this can lead
dar_manager to restored a wrong version of these files
Some files do not follow chronological order when archive index increases
withing the database, this can lead dar_manager to restored a wrong version of
these files
DARsystem: Warning: Adding DARsystemDiff01 to DARsystemDataBase failed.
[End of errors]
I note that between the two archives I did do a large "aptitude upgrade",
upgrading many packages. And I note that all the files complained about are
files from packages. Most of them are .png files but there are others
(including many from /usr/bin).
Looking at the "dar -l" output from the two archives for one of the files I
note that the earlier archive shows:
[Saved] [ 52%][ ] -rwxr-xr-x root root 2387 Wed Jan 19 22:07:51 2011 usr/bin/wcgrep
And the later archive shows:
[Saved] [ 52%][ ] -rwxr-xr-x root root 2387 Tue Jan 29 09:18:04 2008 usr/bin/wcgrep
So, the problem appears to be because the later archive has an earlier mtime
for the file (year 2008 instead of 2011). However, I believe it has a later
ctime so dar appears to be using the wrong time field in its checking.
I can reproduce the bug using the following script, in a clean directory:
#!/bin/sh
mkdir a
echo "First version" >a/test
tar cf test.earlier.tar a
sleep 60
echo "Second version" >a/test
tar cf test.later.tar a
rm -rf a
tar xf test.later.tar
ls -l a/test
ls -lc a/test
ls -la a/test
dar -c first -g a
tar xf test.earlier.tar
ls -l a/test
ls -lc a/test
ls -la a/test
dar -c second -g a -A first
dar_manager -C testdb
dar_manager -B testdb -A first
dar_manager -B testdb -A second
This completely breaks dar's incremental backup feature.
Debian Release: wheezy/sid
APT prefers testing
APT policy: (990, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_IE@euro, LC_CTYPE=en_IE@euro (charmap=ISO-8859-15) (ignored: LC_ALL set to en_IE@euro)
Shell: /bin/sh linked to /bin/bash
Versions of packages dar depends on:
ii libattr1 1:2.4.46-5
ii libbz2-1.0 1.0.6-1
ii libc6 2.13-27
ii libdar64-5 2.4.2-1
ii libgcc1 1:4.6.3-1
ii libgcrypt11 1.5.0-3
ii libgpg-error0 1.10-3
ii liblzo2-2 2.06-1
ii libstdc++6 4.6.3-1
ii zlib1g 1:1.2.6.dfsg-2
dar recommends no packages.
Versions of packages dar suggests:
pn dar-docs 2.4.2-1
pn par2 <none>
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Similar topics
Make your own search :
Tags
Create a new topic
Follow the discussion
3 replies
Make a reply
June 20th, 2013 - 3:08 AM ET
Join now


Replies