Cleanup with Paramiko backend does not remove files due to missing filename byte decoding

Bug #1887689 reported by Matthew Barry
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Fix Released

Bug Description

Duplicity Version: 0.8.12;
Python Version: 3.8.3;
OS Distro and version: Arch Linux 2020-07-15;
Target filesystem: Linux (Ubuntu 18.04.4 LTS) via scp (paramiko)

Log output does not reveal underlying issue.

When running duplicity --cleanup --force scp://user@host//path/to/backup, files to be removed are not actually removed.

Further investigation revealed the path used by SSHParamikoBackend._delete() (at as of commit 4d4b1673) gets interpolated as follows:

    rm '/path/to/backup/b'''
    rm '/path/to/backup/b'''
    rm '/path/to/backup/b'''

The cause of this is that the 'filename' parameter to _delete() is a byte object.

The implementations for _put() and _get() in the same backend convert the remote filename to a string as follows:

    def _get(self, remote_filename, local_path):
        # remote_filename is a byte object, not str or unicode
        remote_filename = remote_filename.decode(u"utf-8")

Note: other backends use the duplicity.util.fsdecode function, which seems like it should be the preferred decoding method.

Proposed solution (see attached git patch file):

1. Replace remote filename decoding in other SSHParamikoBackend methods with util.fsdecode()

2. Add 'filename = util.fsdecode(filename)' as the first line of SSHParamikoBackend._delete() to parallel the treatment of remote filenames in other methods.

Revision history for this message
Matthew Barry (komputerwiz) wrote :
Changed in duplicity:
status: New → Fix Committed
importance: Undecided → Medium
milestone: none → 0.8.15
Changed in duplicity:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers