rdiffdir patch crashes if a file is changed to a non-regular file (symlink, fifo, ...)

[Samu Nuutamo]

Duplicity version: 0.6.23-1ubuntu4.1
Python version: 2.7.6
Distro: Ubuntu 14.04 64bit

Traceback from the error:

Patching testfile
Traceback (most recent call last):
  File "/usr/bin/rdiffdir", line 232, in <module>
    main()
  File "/usr/bin/rdiffdir", line 219, in main
    patch(file_args[0], get_fileobj(file_args[1], "rb"))
  File "/usr/bin/rdiffdir", line 191, in patch
    patchdir.Patch(path.Path(dirname), deltafp)
  File "/usr/lib/python2.7/dist-packages/duplicity/patchdir.py", line 47, in Patch
    patch_diff_tarfile( base_path, diff_tarfile )
  File "/usr/lib/python2.7/dist-packages/duplicity/patchdir.py", line 78, in patch_diff_tarfile
    ITR( basis_path.index, basis_path, diff_ropath )
  File "/usr/lib/python2.7/dist-packages/duplicity/lazy.py", line 335, in __call__
    last_branch.fast_process, args)
  File "/usr/lib/python2.7/dist-packages/duplicity/robust.py", line 37, in check_common_error
    return function(*args)
  File "/usr/lib/python2.7/dist-packages/duplicity/patchdir.py", line 300, in fast_process
    assert diff_ropath.difftype == "diff", diff_ropath.difftype
AssertionError: snapshot

I'm not sure if this is a bug in delta generation or patching, but maybe it should be fixed in both ends. The delta file could include a delete for the original file before the symlink is created, and patching could add a special case for the reg->sym change.

Here's a sample script to reproduce this:

#!/bin/sh
if [ "$1" = "" ]; then
    echo "Usage: $0 <workdir>"
    exit 1
fi

set -x

cd $1

rm -f rdiff-signature rdiff-delta
rm -rf source target

mkdir source target

touch source/testfile
ln -s otherfile target/testfile

rdiffdir -v9 sig source rdiff-signature
rdiffdir -v9 delta rdiff-signature target rdiff-delta
rdiffdir -v9 patch source rdiff-delta

[Samu Nuutamo (carbon)]

Here's a patch that fixes the rdiffdir patch command for me. I'm not sure if the difftype == "snapshot" is the correct way to detect a symlink, but it seems to work fine.

It looks like this bug affects other types of non-regular files as well (e.g. fifos).