giseldo/neodataset huggingface dataset:
"No such file or directory" during backup (lp:#1318833)

[Original report](https://bugs.launchpad.net/bugs/1318833) created by **Michael Terry (mterry)**
```
I have an automatic backup system setup running through a script in
anacron. After upgrading to 14.04 duplicity fails with the following error
(when run from termina)
Traceback (most recent call last):
  File "/usr/bin/duplicity", line 1494, in <module>
    with_tempdir(main)
  File "/usr/bin/duplicity", line 1488, in with_tempdir
    fn()
  File "/usr/bin/duplicity", line 1337, in main
    do_backup(action)
  File "/usr/bin/duplicity", line 1458, in do_backup
    full_backup(col_stats)
  File "/usr/bin/duplicity", line 542, in full_backup
    globals.backend)
  File "/usr/bin/duplicity", line 403, in write_multivol
    globals.gpg_profile, globals.volsize)
  File "/usr/lib/python2.7/dist-packages/duplicity/gpg.py", line 327, in
GPGWriteFile
    bytes_to_go = data_size - get_current_size()
  File "/usr/lib/python2.7/dist-packages/duplicity/gpg.py", line 320, in
get_current_size
    return os.stat(filename).st_size
OSError: [Errno 2] No such file or directory: '/tmp/duplicity-Hy90rz-
tempdir/mktemp-SB_XJ9-2'

I am running 14.04 fully updated and
duplicity:
  Installed: 0.6.23-1ubuntu4
  Candidate: 0.6.23-1ubuntu4
  Version table:
 *** 0.6.23-1ubuntu4 0
        500 http://archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
        100 /var/lib/dpkg/status

Any help?
```

Story points: 86.0
Add tilde expansion in file selection (lp:#1315715)

[Original report](https://bugs.launchpad.net/bugs/1315715) created by **Jon Black (juan-black)**
```
I'm want to backup my home folder but exclude all hidden files and folder.
If I try the option `--exclude .*` I get the error:

Fatal Error: The file specification
    .*
cannot match any files in the base directory
    /home/jon

However, if I use the option `--exclude /home/jon/.*` it works fine. This
is very contradicting.

duplicity version: 0.6.23
```

Story points: 6.0
deja duplicity fails, backup and restore, unknown error (lp:#1314984)

[Original report](https://bugs.launchpad.net/bugs/1314984) created by **dancing (dancingmusic)**
```
unknown error upon either backup or restore
Ubuntu 13.10, Linux ext4 target, restore to Linux external ext3

Traceback (most recent call last):
  File "/usr/bin/duplicity", line 1434, in <module>
    with_tempdir(main)
  File "/usr/bin/duplicity", line 1428, in with_tempdir
    fn()
  File "/usr/bin/duplicity", line 1274, in main
    globals.lockfile.acquire(timeout = 0)
  File "/usr/lib/python2.7/dist-packages/lockfile.py", line 239, in acquire
    raise LockFailed("failed to create %s" % self.unique_name)
LockFailed: failed to create /home/a/.cache/deja-
dup/044e94704d3a9bd7c32d653e5dfdbbc0/star.MainThread-6825

Tried uninstalling deja dup and reinstalling, but there were dependency
problems and neither worked from Software or Synaptic

I don't know how to tell the version, or how to run it in a terminal, so I
don't know how to get the -v9 option, but will be happy to do so with
instructions.

History: Did a successful backup and restore of Home, as myself. Did a
backup of / as myself (couldn't figure out how to run it as root) to a
different directory, which had an error near the end of the process, but
was able to restore some of the files anyway (which I deleted later,
figuring I'd do it over), but now the above error message occurs on either
backup or restore. There were two screens saying I had to authenticate to
run ~bin.sh.
```
Original tags: backup deja-dup duplicity error unknown

Story points: 16.0
Old backups are not deleted on Google Drive (lp:#1306242)

[Original report](https://bugs.launchpad.net/bugs/1306242) created by **Nichlas (nichlas-hummelsberger)**
```
I use version 0.6.23 and backup my files to Google Drive with the gdocs
command.

My problem is that duplicity don't delete old full backups when i ask it to
cleanup.

Instead all the files end up as files with no category/folder, and are
still taking up a lot of space - and because there are a large number of
files it is not trivial to find them and delete them (this is mostly
Google's fault, as it is hard to finde files with no folder, that also
don't belong in the top folder).

The only other mention i found about this was this mail on the mailing
list: https://lists.nongnu.org/archive/html/duplicity-
talk/2013-03/msg00024.html that sadly never got any answer.
```
Original tags: gdocs

Story points: 58.0
restore file to a folder (lp:#1302161)

[Original report](https://bugs.launchpad.net/bugs/1302161) created by **Steven Barre (slashterix)**
```
if --files-to-restore is a single file, target_dir will be treated as a
filename.

if target_dir exists but is empty, it is first deleted then replaced with a
file of the same name.

There appears to be no way to restore a single file to a folder.

I'm building a wrapper, so I don't know if --files-to-restore is a single
file or a folder, else I could just append the basename to my target_dir
```

Story points: 6.0
collection-status should list dates in a format accepted by restore -t (lp:#1302151)

[Original report](https://bugs.launchpad.net/bugs/1302151) created by **Steven Barre (slashterix)**
```
The date/time printed out by collection-status are not acceptable for -t on
restore. This means wrapping tools need to parse and transform the date.

Would also be nice if the collection-status could optionally be returned as
XML/JSON or some other markup for easier parsing.

duplicity 0.6.21 (January 23, 2013)
Linux XXX 2.6.32-431.el6.x86_64 #1 SMP Fri Nov 22 03:15:09 UTC 2013 x86_64
x86_64
/usr/bin/python 2.6.6 (r266:84292, Nov 22 2013, 12:16:22)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-4)]
CentOS 6.5
```

Story points: 10.0
limit upload/download bandwidth (lp:#1291633)

[Original report](https://bugs.launchpad.net/bugs/1291633) created by **hovis (hovis)**
```
It would be useful to have the option to restrict the bandwidth Duplicity
uses when uploading/downloading.  Ie, on a 10Mb line, restrict to 5Mb so
the line is not saturated during a long backup.

One option when using scp:// used to be to add:-

--scp-command "scp -l 5120"

but this no longer works due to scp-command option being depreciated.  Can
a generic 'bandwidth limit' option be added?
```
Original tags: bandwidth rate restrict

Story points: 22.0
Failure to restore. Failed with unkown error: KeyError: 1 (lp:#1283799)

[Original report](https://bugs.launchpad.net/bugs/1283799) created by **dejuoops (stu3cla)**
```
I have Duplicity version 0.6.18. Python 2.7. I using Ubuntu 12.04 LTS, with
this as the target filesystem.

The response I get when I try to restore is this:

Traceback (most recent call last):
  File "/usr/bin/duplicity", line 1414, in <module>
    with_tempdir(main)
  File "/usr/bin/duplicity", line 1407, in with_tempdir
    fn()
  File "/usr/bin/duplicity", line 1341, in main
    restore(col_stats)
  File "/usr/bin/duplicity", line 632, in restore
    restore_get_patched_rop_iter(col_stats)):
  File "/usr/lib/python2.7/dist-packages/duplicity/patchdir.py", line 526,
in Write_ROPaths
    for ropath in rop_iter:
  File "/usr/lib/python2.7/dist-packages/duplicity/patchdir.py", line 498,
in integrate_patch_iters
    for patch_seq in collated:
  File "/usr/lib/python2.7/dist-packages/duplicity/patchdir.py", line 380,
in yield_tuples
    setrorps( overflow, elems )
  File "/usr/lib/python2.7/dist-packages/duplicity/patchdir.py", line 369,
in setrorps
    elems[i] = iter_list[i].next()
  File "/usr/lib/python2.7/dist-packages/duplicity/patchdir.py", line 113,
in difftar2path_iter
    tarinfo_list = [tar_iter.next()]
  File "/usr/lib/python2.7/dist-packages/duplicity/patchdir.py", line 330,
in next
    self.set_tarfile()
  File "/usr/lib/python2.7/dist-packages/duplicity/patchdir.py", line 324,
in set_tarfile
    self.current_fp = self.fileobj_iter.next()
  File "/usr/bin/duplicity", line 668, in get_fileobj_iter
    backup_set.volume_name_dict[vol_num],
KeyError: 1

I would much appreciate it is someone could help me, I really need to get
my files restored.
```

Story points: 10.0
broken with newest pyrax  (lp:#1283738)

[Original report](https://bugs.launchpad.net/bugs/1283738) created by **Simao (simaomm)**
```
After upgrading to duplicity 0.6.23-0ubuntu0ppa21~saucy1 cloudfiles support
no longer works.

First it fails saying the `cf+http` backend requires `pyrax`:

    BackendException: This backend requires the pyrax library available
from Rackspace.

After installing pyrax with `sudo pip install pyrax`, I get the following
error:

Traceback (most recent call last):
  File "/usr/bin/duplicity", line 1489, in <module>
    with_tempdir(main)
  File "/usr/bin/duplicity", line 1483, in with_tempdir
    fn()
  File "/usr/bin/duplicity", line 1317, in main
    action = commandline.ProcessCommandLine(sys.argv[1:])
  File "/usr/lib/python2.7/dist-packages/duplicity/commandline.py", line
1027, in ProcessCommandLine
    globals.backend = backend.get_backend(args[0])
  File "/usr/lib/python2.7/dist-packages/duplicity/backend.py", line 162,
in get_backend
    return _backends[pu.scheme](pu)
  File "/usr/lib/python2.7/dist-packages/duplicity/backends/_cf_pyrax.py",
line 73, in __init__
    self.container = pyrax.cloudfiles.create_container(container)
AttributeError: 'NoneType' object has no attribute 'create_container'


Also, there is the `--cf-backend` option documented in the man page, but
duplicity doesn't actually support it:

duplicity: error: no such option: --cf-backend



duplicity 0.6.23
Python 2.7.5+
Ubuntu 13.10
```

Story points: 8.0
Deja-Dup Restore Failure on FC19 (lp:#1276345)

[Original report](https://bugs.launchpad.net/bugs/1276345) created by **Val Eckertson (j-valeck)**
```
Fedora 19 x86_64

Latest version

Restore error: Failed to read /home/val/.cache/deja-
dup/tmp/duplicity-Y35aSf-tempdir/mktemp-2f1ney-1: (<type
'exceptions.IOError'>, IOError('CRC check failed 0xac6a31db !=
0xbef8d0d5L',), <traceback object at 0x1b317e8>)


3. No such file found

4. No such file found

Please see http://forums.fedoraforum.org/showthread.php?t=295900


Bug Submitted to Red Hat Bugzilla # 1060956


email: j.valeck@gmail.com
```

Story points: 8.0
UTF-8 comparison issue when using globbing file on Mac (lp:#1272814)

[Original report](https://bugs.launchpad.net/bugs/1272814) created by **Lucas (public-k)**
```
I've run into problems when using UTF-8 characters in a globbing file on OS
X.

So I'm trying to include a directory, let's call it "Geschäftlich", which
contains a German umlaut. Said character may be represented in two (perhaps
more) ways:

    Gesch\xc3\xa4ftlich

This is the way my editor chose to represent it, as U+00E4, or "LATIN SMALL
LETTER A WITH DIAERESIS". Unfortunately, my operating system begs to
differ, and chooses the following form:

    Gescha\xcc\x88ftlich

Here we have a plain old "a" character followed by U+0308, the "COMBINING
DIAERESIS", which results in the same visual representation. The problem is
then, that:

    >>> "Gesch\xc3\xa4ftlich" == "Gescha\xcc\x88ftlich"
    False

So apparently the way to fix this is to "normalize" both unicode strings
before comparison (http://stackoverflow.com/questions/16467479), like so:

    import unicodedata
    a = unicode("Gesch\xc3\xa4ftlich", "UTF-8")
    b = unicode("Gescha\xcc\x88ftlich", "UTF-8")

    >>> unicodedata.normalize("NFC", a) == unicodedata.normalize("NFC", b)
    True

In the above example, NFC stands for "Normal Form Composed", as opposed to
"Normal Form Decomposed" (NFD). Whether or not it is relevant which one you
choose I have not figured out yet.

I've figured out that the comparisons that fail due to this unicode snafu
seem to be implemented inside the functions generated by
"glob_get_tuple_sf" in "selection.py", but since I'm looking at the
Duplicity source for the first time, it's kind of hard to tell whether or
not this would've do be done elsewhere as well. I'd be willing to write a
patch if someone would provide me with a little guidance on the matter :)

Python Version: 2.7.5
Duplicity Version: 0.6.22
OS: Mac OS X 10.9
```

Story points: 6.0
UnicodeEncodeError after Dropbox backup is done (lp:#1271481)

[Original report](https://bugs.launchpad.net/bugs/1271481) created by **Miro Hrončok (churchyard)**
```
Hi, I've got this eror each time I use Dropbox backend:
$ duplicity ~ dpbx://
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: Tue Jan 14 12:51:14 2014
GnuPG passphrase:
Retype passphrase to confirm:
--------------[ Backup Statistics ]--------------
StartTime 1390385907.82 (Wed Jan 22 11:18:27 2014)
EndTime 1390385950.76 (Wed Jan 22 11:19:10 2014)
ElapsedTime 42.94 (42.94 seconds)
SourceFiles 78321
SourceFileSize 9838764906 (9.16 GB)
NewFiles 1283
NewFileSize 50808455 (48.5 MB)
DeletedFiles 12
ChangedFiles 211
ChangedFileSize 62205324 (59.3 MB)
ChangedDeltaSize 0 (0 bytes)
DeltaEntries 1506
RawDeltaSize 59932930 (57.2 MB)
TotalDestinationSizeChange 22618861 (21.6 MB)
Errors 0
-------------------------------------------------

Exception ['ascii' codec can't encode character u'\u010d' in position 30:
ordinal not in range(128)]:
| Traceback (most recent call last):
|   File "/usr/lib64/python2.7/site-
packages/duplicity/backends/dpbxbackend.py", line 83, in wrapper
|     return f(self, *args)
|   File "/usr/lib64/python2.7/site-
packages/duplicity/backends/dpbxbackend.py", line 192, in close
|     log.Debug(':: %s=[%s]'%(k,info[k]))
|   File "/usr/lib64/python2.7/site-packages/duplicity/log.py", line 83, in
Debug
|     Log(s, DEBUG)
|   File "/usr/lib64/python2.7/site-packages/duplicity/log.py", line 75, in
Log
|     _logger.log(DupToLoggerLevel(verb_level), s.decode("utf8", "ignore"))
|   File "/usr/lib64/python2.7/encodings/utf_8.py", line 16, in decode
|     return codecs.utf_8_decode(input, errors, True)
| UnicodeEncodeError: 'ascii' codec can't encode character u'\u010d' in
position 30: ordinal not in range(128)
dpbx code error "'ascii' codec can't encode character u'\u010d' in position
30: ordinal not in range(128)"
Traceback (most recent call last):
  File "/usr/bin/duplicity", line 1466, in <module>
    with_tempdir(main)
  File "/usr/bin/duplicity", line 1459, in with_tempdir
    fn()
  File "/usr/bin/duplicity", line 1442, in main
    globals.backend.close()
  File "/usr/lib64/python2.7/site-
packages/duplicity/backends/dpbxbackend.py", line 94, in wrapper
    raise e
UnicodeEncodeError: 'ascii' codec can't encode character u'\u010d' in
position 30: ordinal not in range(128)

=== EOF ===

It seems not to affect the backup.

$ rpm -q duplicity
duplicity-0.6.22-1.fc20.x86_64
$ rpm -q python
python-2.7.5-9.fc20.x86_64
$ cat /etc/redhat-release
Fedora release 20 (Heisenbug)
```

Story points: 8.0
"IOError: [Errno 71] Protocol error" during restore (lp:#1268558)

[Original report](https://bugs.launchpad.net/bugs/1268558) created by **Andre (gestatten-cox)**
```
During the encrypted restore the software crashes. Always on the same file.
What can I do since my PC crashed and I need the restore urtgently? Tried
different versions and even on different linux PCs. Same issue on the same
file. Please help


Traceback (most recent call last):

  File "/usr/bin/duplicity", line 1414, in <module>

    with_tempdir(main)

  File "/usr/bin/duplicity", line 1407, in with_tempdir

    fn()

  File "/usr/bin/duplicity", line 1341, in main

    restore(col_stats)

  File "/usr/bin/duplicity", line 632, in restore

    restore_get_patched_rop_iter(col_stats)):

  File "/usr/lib/python2.7/dist-packages/duplicity/patchdir.py", line 528,
in Write_ROPaths

    ITR( ropath.index, 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 581,
in fast_process

    ropath.copy( self.base_path.new_index( index ) )

  File "/usr/lib/python2.7/dist-packages/duplicity/path.py", line 426, in
copy

    other.writefileobj(self.open("rb"))

  File "/usr/lib/python2.7/dist-packages/duplicity/path.py", line 600, in
writefileobj

    fout = self.open("wb")

  File "/usr/lib/python2.7/dist-packages/duplicity/path.py", line 542, in
open

    result = open(self.name, mode)

IOError: [Errno 71] Protocol error:
'/media/sf_Documents/restore/home/ubuntu/Documents/business/shopic
Lampen/Invoices/Rechnung 2356015\n.pdf'
```

Story points: 8.0
Automatic Backup after fresh install of trusty fails: no such file or directory (lp:#1267590)

[Original report](https://bugs.launchpad.net/bugs/1267590) created by **David Ayers (ayers)**
```
While testing da daily snapshot to verfy a different issue I configured
deja-dup to add the typical load to my system.

I configured an SSH upload.

deja-dup failed with:
Traceback (most recent call last):
  File "/usr/bin/duplicity", line 1473, in <module>
    with_tempdir(main)
  File "/usr/bin/duplicity", line 1466, in with_tempdir
    fn()
  File "/usr/bin/duplicity", line 1436, in main
    full_backup(col_stats)
  File "/usr/bin/duplicity", line 541, in full_backup
    globals.backend)
  File "/usr/bin/duplicity", line 402, in write_multivol
    globals.gpg_profile, globals.volsize)
  File "/usr/lib/python2.7/dist-packages/duplicity/gpg.py", line 324, in
GPGWriteFile
    file = GPGFile(True, path.Path(filename), profile)
  File "/usr/lib/python2.7/dist-packages/duplicity/gpg.py", line 105, in
__init__
    self.logger_fp = tempfile.TemporaryFile( dir=tempdir.default().dir() )
  File "/usr/lib/python2.7/tempfile.py", line 493, in TemporaryFile
    (fd, name) = _mkstemp_inner(dir, prefix, suffix, flags)
  File "/usr/lib/python2.7/tempfile.py", line 239, in _mkstemp_inner
    fd = _os.open(file, flags, 0600)
OSError: [Errno 2] No such file or directory: '/tmp/duplicity-dH5tyj-
tempdir/tmpTVOITr'

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: deja-dup 29.1-0ubuntu4
ProcVersionSignature: Ubuntu 3.13.0-1.16-generic 3.13.0-rc7
Uname: Linux 3.13.0-1-generic x86_64
ApportVersion: 2.12.7-0ubuntu6
Architecture: amd64
CurrentDesktop: Unity
Date: Thu Jan  9 21:36:37 2014
InstallationDate: Installed on 2014-01-09 (0 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Alpha amd64 (20140109)
SourcePackage: deja-dup
UpgradeStatus: No upgrade log present (probably fresh install)
```
Original tags: amd64 apport-bug trusty

Story points: 14.0
backup folder in ~/.cache/deja-dup/tmp does not exist (lp:#1266025)

[Original report](https://bugs.launchpad.net/bugs/1266025) created by **Andreas E. (andreas-e)**
```
Déjà-dup backups fail with an error message "The backup folder
»/home/username/.cache/deja-dup/tmp/duplicity-il-
Au69-tempdir/mktemp-51Sz0x-3« does not exist.". This folder does indeed not
exist. When clicking the close button, deja-dup aborted.

For weeks not a single deja-dup backup completed successfully due to
various reported bugs. When I attempt to restore files, I see that files
have been backuped, but I cannot be sure whether the files are complete.
This makes the backups absolutely useless because I have no guarantee that
I can restore all the files.

I would strongly recommend to review _all_ error messages that deja-dup
might produce and allow users to continue an interrupted backup process
when the issue has been resolved.
```

Story points: 6.0
Cannot restore backup copy (lp:#1265676)

[Original report](https://bugs.launchpad.net/bugs/1265676) created by **Edgar Ramón Herrera Morgado (e-r-h-m)**
```
Traceback (most recent call last):
  File "/usr/bin/duplicity", line 1414, in <module>
    with_tempdir(main)
  File "/usr/bin/duplicity", line 1407, in with_tempdir
    fn()
  File "/usr/bin/duplicity", line 1289, in main
    globals.archive_dir).set_values()
  File "/usr/lib/python2.7/dist-packages/duplicity/collections.py", line
693, in set_values
    self.get_backup_chains(partials + backend_filename_list)
  File "/usr/lib/python2.7/dist-packages/duplicity/collections.py", line
816, in get_backup_chains
    map(add_to_sets, filename_list)
  File "/usr/lib/python2.7/dist-packages/duplicity/collections.py", line
806, in add_to_sets
    if set.add_filename(filename):
  File "/usr/lib/python2.7/dist-packages/duplicity/collections.py", line
97, in add_filename
    (self.volume_name_dict, filename)
AssertionError: ({ All files --- Todos los archivos})
```

Story points: 6.0
doesn't work with Python 2.4 in RHEL 5 (lp:#1264847)

[Original report](https://bugs.launchpad.net/bugs/1264847) created by **Rahul Sundaram (metherid)**
```
Duplicity README claims compatibility with 2.4 however it doesn't start
with the base version of Python in RHEL 5

https://bugzilla.redhat.com/show_bug.cgi?id=976873
```

Story points: 6.0
Australian/Asian S3 buckets (lp:#1261246)

[Original report](https://bugs.launchpad.net/bugs/1261246) created by **Daniel Lo Nigro (daniel15)**
```
The manpage for Duplicity mentions European S3 buckets (and the
--s3-european-buckets option) but has no mention of other regions, like
Asia/Australia.
```

Story points: 6.0
"BackendException: ssh connection failed: 'SSHClient' object has no attribute 'known_hosts'" (lp:#1260541)

[Original report](https://bugs.launchpad.net/bugs/1260541) created by **iceflatline (iceflatline)**
```
I'm receiving the following error when running the duplicity in conjunction
with the verify command:

"BackendException: ssh connection to [host:port] failed: 'SSHClient' object
has no attribute 'known_hosts'"

The command I'm using is constructed as follows:

/usr/local/bin/duplicity verify --include /mnt/files/backup/ --exclude '**'
scp://backup@<host>//mnt/backup/weekly/ /mnt/files/

This has worked perfectly up until a new IP address was assigned to [host].
Now of course the system needs to (re)confirm my intent to connect but
can't populate a known_hosts file.

Using duplicity-0.6.22_1 under FreeBSD 9.2-RELEASE. Target [host] is also
FreeBSD 9.2-RELEASE.

Note these are not VMs, therefore this bug  appears to be different the one
reported under Bug #1197092 .

Suggested work-arounds for this problem would be appreciated.
```

Story points: 6.0
Duplicity downloads old signatures when they are irrelevant (lp:#1258584)

[Original report](https://bugs.launchpad.net/bugs/1258584) created by **Dan Flexy (o-m7-q)**
```
I wonder why Duplicity is not smart enough not to download old signatures
when they are irrelevant for the task in hand?

Doing a standard, last backup restore. There is a full backup made few days
ago and a couple of relevant incremental changes.

Instead of downloading last duplicity-full file and it's increments,
duplicity starts to pull all signatures since a year ago!
WHY? As they are totally irrelevant for the task requested.

I know I can clean them up, but this is not what I want to do as they are
kept in case point in time recovery is needed.

Hasn't the authors thought this simple behaviour or is there a reason it
downloads all these old signatures?
```

Story points: 6.0