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

Remote bug watches

Bug watches keep track of this bug in other bug trackers.