rdiff-backup-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[rdiff-backup-users] Backup of .xls and .ppt files


From: Remy Blank
Subject: [rdiff-backup-users] Backup of .xls and .ppt files
Date: Thu, 03 Feb 2011 19:29:58 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.24) Gecko/20100228 Thunderbird/2.0.0.24 Mnenhy/0.7.5.0

Did anyone else notice that rdiff-backup doesn't detect certain
modifications of .xls or .ppt files correctly?

My setup is a Linux server running Samba, and Windows clients accessing
a share on the server. The share is backed up with rdiff-backup on the
server itself. The filesystem is ext3.

Today I ran a --compare-full between the share and the backup, and I got
lots of "metadata the same, data changed:" messages on .xls and .ppt
files. Comparing the hex dumps of those files with the backup shows that
they each have two very small differences, one probably containing the
user name of the last person who opened the file, and the other one
presumably the time of the last open.

It seems that when an Excel or PowerPoint file is opened and closed
without saving, the content is changed, the file size remains constant,
and the mtime is set back to its value prior to the change.

Of course, this is very, very bad practice, and it breaks rdiff-backup's
change detection algorithm. But I still would like to have a consistent
backup of these files. There doesn't seem to be an option to always
check the content, like rsync -c does. So currently, my only option is
to change the mtime of all .xls and .ppt files regularly, which brings
its own set of issues.

Would it be possible to add an option to specify a list of extensions,
where the change detection algorithm for files with the given extensions
would always check the content of the file, even if the size and mtime
matches? The Unison file synchronizer has exactly such an option, with a
default including .xls, .ppt and IIRC .mpp.

I can try implementing the functionality myself, if someone can point me
in the right direction.

-- Remy

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]