SearchFAQMemberlist Log in
Reply to topic Page 1 of 1
Bug report: Symbolic link replacing directory
Author Message
Post Bug report: Symbolic link replacing directory 
Hi all!

How to confuse a backup system? Maybe you should try this approach, it
worked for me. :-(

Confusion recipe for rdiff-backup V12.6:

Create two directories (dir1 and dir2).
Create two files, dir1/file1 and dir2/file2.
Backup the stuff.
Move file2 to dir1/file2.
Remove dir2.
Symlink dir2 -> dir1
Backup the stuff.

This gives the following error message:

UpdateError dir1/file2 File changed from regular file before signature.

And file2 is not in the backup.

I cannot see any mention of this behaviour in the changelog of V12.7,
so I gues this version should do the same. Otherwise I would have
updated and tested again.

As a workaround to this bug, I thought about deleting dir2 in the
increment directory. That way I would lose old history, but that
doesn`t really matter. But what to do with the metadata, so the whole
backup remains consistent?

Open Christmas
John

Post Bug report: Symbolic link replacing directory 
john wrote:
Hi all!

How to confuse a backup system? Maybe you should try this approach, it
worked for me. :-(

Confusion recipe for rdiff-backup V12.6:

Create two directories (dir1 and dir2).
Create two files, dir1/file1 and dir2/file2.
Backup the stuff.
Move file2 to dir1/file2.
Remove dir2.
Symlink dir2 -> dir1
Backup the stuff.

This gives the following error message:

UpdateError dir1/file2 File changed from regular file before signature.

And file2 is not in the backup.

I cannot see any mention of this behaviour in the changelog of V12.7,
so I gues this version should do the same. Otherwise I would have
updated and tested again.

As a workaround to this bug, I thought about deleting dir2 in the
increment directory. That way I would lose old history, but that
doesn`t really matter. But what to do with the metadata, so the whole
backup remains consistent?

Wouldnt it be better to remove dir2 , and not create the symlink until
after a backup has run.

Another approach, depending on how much data there is, is to first do a
hardlink. something like:
mkdir dir1 dir2
for FILE in dir1/file1 dir2/file2 ; do
echo $FILE > $FILE
done
rdiff-backup --add-your-options
ln dir2/file2 dir1
rdiff-backup --add-your-options
rm -rf dir2
rdiff-backup --add-your-options
ln -s dir1 dir2
rdiff-backup --add-your-options

I guess that will cause less pain to your backup, but I'm not sure.

// faj

Post Bug report: Symbolic link replacing directory 
Hi,

On Thu, 23 Dec 2004, john wrote:

How to confuse a backup system? Maybe you should try this approach, it
worked for me. :-(

There have been other threads about problems with special files (like
symlinks). Even so far as deleted _source_ trees because of symlink
handling. As a workaround (and no, I do not quite like it this way) I make
a .tgz of all special files and then exclude all special files when
invoking rdiff-backup.
Restoring is a bit more compilated that way though, so make sure you know
what's going on.

What I'd like to see, is an option to have special files exist _only_ in
metadata, not on disk. This would enable backing up to file systems
without notion of ownership and file types, like vfat.

Kind regards,
Maarten Bezemer

Post Bug report: Symbolic link replacing directory 
There have been other threads about problems with special files
(like symlinks).

Okay, I do not read the mailing list regularly. On the other hand: The
feature list on the homepage does clearly say, that symlinks are
supported, which they definetly are, but I couldn`t find any bug list on
the homepage. Isnīt there any?

I consider this bug as severe, as quite a lot of files can be missing
in the backup set (and were missing). I`m currently fixing that by
deleting those files and the metadata of the current backup, so the
next backup run should recreate them synchron to the source.

Even so far as deleted _source_ trees because of symlink
handling.

Are you sure? This would be worse than severe. As long as my source
data is untouched I always can run diffs between source and backup and
find rdiff errors, like that one, and can fix it. Not very nice, but
kinda save.

But an error condition like that is untrackable without a
backup... Can you give me a pointer to that kind of error, I really
want to know what I am dealing with here. Maybe I have to drop
rdiff-backup, because it`s to risky to use.

What I'd like to see, is an option to have special files exist _only_ in
metadata, not on disk. This would enable backing up to file systems
without notion of ownership and file types, like vfat.

Would be nice, agreed. But shouldn`t it first work correctly on unix
filesystems?

cu
John

Display posts from previous:
Reply to topic Page 1 of 1
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
  


Magic SEO URL for phpBB