giseldo/neodataset huggingface dataset:
Uploading full signatures for large backup set fails with B2 backend (lp:#1544707)

[Original report](https://bugs.launchpad.net/bugs/1544707) created by **Maakuth (markus-vuorio)**
```
I have a backup set of around 450GiB. Uploading it to B2 went fine, but at
the end the backing up wasn't successful. I've tied it multiple times, but
it always comes down to the same issue:

...
Processed volume 17633
Writing duplicity-full-signatures.20151212T092152Z.sigtar.gpg
Attempt 1 failed. SSLError: ('The read operation timed out',)
Writing duplicity-full-signatures.20151212T092152Z.sigtar.gpg
Attempt 2 failed. SSLError: ('The read operation timed out',)
Writing duplicity-full-signatures.20151212T092152Z.sigtar.gpg
Attempt 3 failed. SSLError: ('The read operation timed out',)
Writing duplicity-full-signatures.20151212T092152Z.sigtar.gpg
Attempt 4 failed. SSLError: ('The read operation timed out',)
Writing duplicity-full-signatures.20151212T092152Z.sigtar.gpg
^NGiving up after 5 attempts. URLError: <urlopen error [Errno 104]
Connection reset by peer>

The file in question is around 3.4GiB. I'm thinking there's some special
treatment one should do when uploading such big files to B2, but I'm not
sure. I think B2 is supposed to support files up to 5GB.

Duplicity 0.7.06
Python 2.7.9
Debian 8.3 "Jessie"
Backing up from an XFS volume to Backblaze B2

I'll submit more log lines once I've captured them to a file.
```
Original tags: b2

Story points: 12.0
Progress should override output (lp:#1537799)

[Original report](https://bugs.launchpad.net/bugs/1537799) created by **Wernight (werner-beroux)**
```
Currently outputs with --progress look like:
2.6GB 00:29:40 [1.6MB/s] [==========>                              ] 26%
ETA 1h 21min
2.6GB 00:29:43 [1.6MB/s] [==========>                              ] 26%
ETA 1h 21min
2.6GB 00:29:46 [1.4MB/s] [==========>                              ] 26%
ETA 1h 21min
2.6GB 00:29:49 [1.5MB/s] [==========>                              ] 26%
ETA 1h 21min
2.7GB 00:29:52 [1.5MB/s] [==========>                              ] 26%
ETA 1h 21min
2.7GB 00:29:55 [1.6MB/s] [==========>                              ] 26%
ETA 1h 21min
2.7GB 00:29:58 [1.6MB/s] [==========>                              ] 26%
ETA 1h 21min
2.7GB 00:30:01 [1.4MB/s] [==========>                              ] 26%
ETA 1h 21min
2.7GB 00:30:04 [1.5MB/s] [==========>                              ] 27%
ETA 1h 21min
2.7GB 00:30:07 [1.5MB/s] [==========>                              ] 27%
ETA 1h 21min
2.7GB 00:30:10 [1.6MB/s] [==========>                              ] 27%
ETA 1h 21min
2.7GB 00:30:13 [1.6MB/s] [==========>                              ] 27%
ETA 1h 20min
2.7GB 00:30:17 [1.6MB/s] [==========>                              ] 27%
ETA 1h 20min
2.7GB 00:30:20 [1.4MB/s] [==========>                              ] 27%
ETA 1h 20min
2.7GB 00:30:23 [1.5MB/s] [==========>                              ] 27%
ETA 1h 20min
2.7GB 00:30:26 [1.6MB/s] [==========>                              ] 27%
ETA 1h 20min
2.7GB 00:30:29 [1.6MB/s] [==========>                              ] 27%
ETA 1h 20min
2.7GB 00:30:32 [1.7MB/s] [==========>                              ] 27%
ETA 1h 20min
2.7GB 00:30:35 [1.4MB/s] [==========>                              ] 27%
ETA 1h 20min
2.7GB 00:30:38 [1.4MB/s] [===========>                             ] 27%
ETA 1h 20min
2.7GB 00:30:41 [1.5MB/s] [===========>                             ] 27%
ETA 1h 20min

It could easily just update that line. There are two simple ways to do that
(in Python):

import sys
from time import sleep

# '\r': Simpler way, having issue when console width is too small and
output gets wrapped.
for i in range(0, 101, 5):
    sys.stdout.write("Download progress: {}%   \r".format(i))
    sys.stdout.flush()

    # Do work here...
    sleep(0.1)
sys.stdout.write('\n')

# '\b': Better way
sys.stdout.write("Download progress: ")
for i in range(0, 101, 5):
    s = '%d%%' % i
    sys.stdout.write(s)

    # Do work here...
    sleep(0.1)

    sys.stdout.write('\b' * len(s))
sys.stdout.write('\n')
```

Story points: 10.0
backblaze connection issue? (lp:#1534663)

[Original report](https://bugs.launchpad.net/bugs/1534663) created by **Steven Verbeek (dubcanada)**
```
Hello,

I am using Duplicity 0.7.06 from the stable branch on Ubuntu 14.04 and I
have tried two different servers on two completely different networks. No
matter what I do I cannot upload to Backblaze B2 using Duplicity, the
Backblaze python pusher and other tools by them all work fine. But
duplicity fails when trying to upload.

Backblaze keeps sending me either

Backtrace of previous error: Traceback (innermost last):
  File "/usr/lib/python2.7/dist-packages/duplicity/backend.py", line 365,
in inner_retry
    return fn(self, *args)
  File "/usr/lib/python2.7/dist-packages/duplicity/backend.py", line 540,
in put
    self.__do_put(source_path, remote_filename)
  File "/usr/lib/python2.7/dist-packages/duplicity/backend.py", line 526,
in __do_put
    self.backend._put(source_path, remote_filename)
  File "/usr/lib/python2.7/dist-packages/duplicity/backends/b2backend.py",
line 116, in _put
    self.get_or_post(url, None, headers, data_file=data_file)
  File "/usr/lib/python2.7/dist-packages/duplicity/backends/b2backend.py",
line 256, in get_or_post
    with OpenUrl(url, data, encoded_headers) as resp:
  File "/usr/lib/python2.7/dist-packages/duplicity/backends/b2backend.py",
line 332, in __enter__
    self.file = urllib2.urlopen(request)
  File "/usr/lib/python2.7/urllib2.py", line 127, in urlopen
    return _opener.open(url, data, timeout)
  File "/usr/lib/python2.7/urllib2.py", line 404, in open
    response = self._open(req, data)
  File "/usr/lib/python2.7/urllib2.py", line 422, in _open
    '_open', req)
  File "/usr/lib/python2.7/urllib2.py", line 382, in _call_chain
    result = func(*args)
  File "/usr/lib/python2.7/urllib2.py", line 1222, in https_open
    return self.do_open(httplib.HTTPSConnection, req)
  File "/usr/lib/python2.7/urllib2.py", line 1184, in do_open
    raise URLError(err)
 URLError: <urlopen error [Errno 104] Connection reset by peer>

or http://laravel.io/bin/kWmnE errors.

I contacted them about the errors and they said they were going to fix the
500 one, so that one can be ignored.
```

Story points: 6.0
0.6.25->0.7.05 fatal performance regression (lp:#1516788)

[Original report](https://bugs.launchpad.net/bugs/1516788) created by **Jan Kratochvil (jan-kratochvil)**
```
Running on updated Fedora 23 x86_64:
duplicity-0.7.05-1.fc23.x86_64
21:57:20 lstat("/etc/rc.d/rc4.d/K74gfs2", {st_mode=S_IFLNK|0777,
st_size=14, ...}) = 0
21:57:20 readlink("/etc/rc.d/rc4.d/K74gfs2", "../init.d/gfs2", 4096) = 14
21:57:24 lstat("/etc/rc.d/rc4.d/K85ebtables", {st_mode=S_IFLNK|0777,
st_size=18, ...}) = 0
21:57:24 readlink("/etc/rc.d/rc4.d/K85ebtables", "../init.d/ebtables",
4096) = 18
21:57:28 lstat("/etc/rc.d/rc4.d/K90network", {st_mode=S_IFLNK|0777,
st_size=17, ...}) = 0
21:57:28 readlink("/etc/rc.d/rc4.d/K90network", "../init.d/network", 4096)
= 17
21:57:33 lstat("/etc/rc.d/rc4.d/S01sandbox", {st_mode=S_IFLNK|0777,
st_size=17, ...}) = 0
21:57:33 readlink("/etc/rc.d/rc4.d/S01sandbox", "../init.d/sandbox", 4096)
= 17
 - it was running for 2 hours and reading each file for 4 seconds is
unusable.
  26.69%  duplicity  libpython2.7.so.1.0  [.] PyEval_EvalFrameEx
   4.73%  duplicity  libc-2.22.so         [.] vfprintf
   3.70%  duplicity  libpython2.7.so.1.0  [.] lookdict_string
   3.70%  duplicity  libpython2.7.so.1.0  [.]
PyUnicodeUCS4_DecodeUTF8Stateful
   3.47%  duplicity  libpython2.7.so.1.0  [.] PyString_Format
   3.11%  duplicity  libpython2.7.so.1.0  [.]
_PyObject_GenericGetAttrWithDict
   3.09%  duplicity  libpython2.7.so.1.0  [.] PyEval_EvalCodeEx
   1.85%  duplicity  libpython2.7.so.1.0  [.] convertitem
   1.85%  duplicity  libpython2.7.so.1.0  [.] PyFrame_New

After downgrading just the package duplicity to 0.6.25 the backup was
successfuly done in 4 minutes, like always before:
duplicity-0.6.25-3.fc21.x86_64
--------------[ Backup Statistics ]--------------
StartTime 1447707702.06 (Mon Nov 16 22:01:42 2015)
EndTime 1447707987.63 (Mon Nov 16 22:06:27 2015)
ElapsedTime 285.57 (4 minutes 45.57 seconds)
SourceFiles 92925
SourceFileSize 2516870978 (2.34 GB)
NewFiles 51428
NewFileSize 179314732 (171 MB)
DeletedFiles 22722
ChangedFiles 1196
ChangedFileSize 284383140 (271 MB)
ChangedDeltaSize 0 (0 bytes)
DeltaEntries 75346
RawDeltaSize 210169249 (200 MB)
TotalDestinationSizeChange 54708267 (52.2 MB)
Errors 0
-------------------------------------------------
11G     host1-backup

Unaware how to do Python-source-level performance monitoring.

duplicity --archive-dir /root/backup/host2-signature2 --allow-source-
mismatch --encrypt-key 1F0D6D7B --sign-key 1F0D6D7B --exclude-other-
filesystems --exclude-filelist /tmp/host2-run.rpmsafe --exclude
/var/spool/squid [...] --exclude
'/usr/lib/jvm/*/jre/lib/amd64/server/classes.jsa' /
file:///host1/root/backup/host2-backup2
3.0G    /root/backup/host2-signature2
68G     /host1/root/backup/host2-backup2
wc -l:
558303 /tmp/host2-run.rpmsafe

python-2.7.10-8.fc23.x86_64
Linux ext4
```

Story points: 6.0
Misleading "Ignoring incremental Backupset" message (lp:#1512055)

[Original report](https://bugs.launchpad.net/bugs/1512055) created by **Tobias G. Pfeiffer (tgpfeiffer)**
```
For a while I have been doing my duplicity backups to Glacier now. First I
used a kind of hack to do a normal AWS upload, then rename all the difftar
files to match S3 lifecycle rules. Using that method, I got "Ignoring
incremental Backupset" messages on subsequent backups, maybe because there
were no data files found using the expected file name pattern.

Then recently I upgraded to the latest duplicity version and switched to
the `--file-prefix-archive` method, which feels a lot better. However, I
still had the "Ignoring incremental Backupset" message in my logs which
confused me a bit, since all commands seem to behave correctly. I found out
that when an incremental backupset is found, `chain.add_inc(set)` is called
on all chains until one of these calls returns True, and every call before
will emit an "Ignoring incremental Backupset" message. So the very normal
operation of "finding the correct chain" emits a message that indicates
something is ignored or missing or not matching etc.

I think the functionality of finding the correct chain should be changed so
that no such warning message is emitted in order to avoid user confusion.
```

Story points: 10.0
pydrive backend cannot recover if remote files missing (lp:#1504908)

[Original report](https://bugs.launchpad.net/bugs/1504908) created by **Kuang-che Wu (kcwu)**
```
How to reproduce
duplicity 0.7.05
1. backup with pydrive backend
2. delete one of manifest.gpg file on remote server
3. run duplicity backup again

error messages:
Attempt 1 failed. AttributeError: 'NoneType' object has no attribute
'GetContentFile'
Attempt 2 failed. AttributeError: 'NoneType' object has no attribute
'GetContentFile'
Attempt 3 failed. AttributeError: 'NoneType' object has no attribute
'GetContentFile'
Attempt 4 failed. AttributeError: 'NoneType' object has no attribute
'GetContentFile'
Giving up after 5 attempts. AttributeError: 'NoneType' object has no
attribute 'GetContentFile'


FYI, I have a patch but I don't know whether it is a correct fix or not.

diff --git a/duplicity/backends/pydrivebackend.py
b/duplicity/backends/pydrivebackend.py
index 2b1a805..4181dd8 100644
--- a/duplicity/backends/pydrivebackend.py
+++ b/duplicity/backends/pydrivebackend.py
@ @ -135,6 +135,8@ @ class PyDriveBackend(duplicity.backend.Backend):

     def _get(self, remote_filename, local_path):
         drive_file = self.file_by_name(remote_filename)
+        if drive_file is None:
+            raise BackendException("failed to get '%s'" % remote_filename)
         drive_file.GetContentFile(local_path.name)

     def _list(self):
```

Story points: 6.0
With 70% free space duplicity dies with [Errno 28] No space left on device:  (lp:#1503960)

[Original report](https://bugs.launchpad.net/bugs/1503960) created by **Wojciech Adam Koszek (wkoszek)**
```
I have the Synology DS214play with Atom CPU and 1GB of RAM. I have RAID
mirror with 2x1TB disks, and 2 USB volumes attached: 320GB and 1TB disk. In
this report I attempt to test-drive duplicity on 1TB volume by running:

root@wkoszek_nas:/mnt/volumeUSB2# time duplicity --no-encryption
/home/wkoszek file://`pwd`/backup-duplicity.20151005 > duplicity.report.txt
[Errno 28] No space left on device: '/mnt/volumeUSB2/backup-
duplicity.20151005/duplicity-full.20151006T085704Z.vol13107.difftar.gz'

real    1724m51.360s
user    1449m55.449s
sys     118m55.726s

Report file:

Local and Remote metadata are synchronized, no sync needed.
Last full backup left a partial set, restarting.
Last full backup date: Tue Oct  6 01:55:12 2015
RESTART: The first volume failed to upload before termination.
         Restart is impossible...starting backup from beginning.
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: none
No signatures found, switching to full backup.

Mount points:

/dev/root              2451064   1594404    754260  68% /
/tmp                    358092       180    357912   1% /tmp
/run                    358092      2544    355548   1% /run
/dev/shm                358092         0    358092   0% /dev/shm
/volume1/homes       956675772 922960672  33612700  97%
/volume1/@appstore/debian-chroot/var/chroottarget/home
/volumeUSB1/usbshare 312494912 153154016 159340896  50%
/volume1/@appstore/debian-chroot/var/chroottarget/mnt/volumeUSB1
/volumeUSB2/usbshare 976251072 335877424 640373648  35%
/volume1/@appstore/debian-chroot/var/chroottarget/mnt/volumeUSB2
/dev                    355860         4    355856   1%
/volume1/@appstore/debian-chroot/var/chroottarget/dev

I run duplicity from chroot'ed Debian environment, with duplicity installed
via apt-get. Version:

root@wkoszek_nas:/mnt/volumeUSB2# duplicity --version
duplicity 0.6.24

Dir entry to the backup directory:

drwxrwxrwx 2 1024 users   2097152 Oct  7 06:41 backup-duplicity.20151005

---------------- this paragraph is wrong and written by mistake ----------

I couldn't figure out what's wrong, but I feel this is a problem:

root@wkoszek_nas:/mnt/volumeUSB2# du -ch backup-duplicity.20151005/
320G    backup-duplicity.20151005/
320G    total

root@wkoszek_nas:/mnt/volumeUSB2# ls -1 backup-duplicity.20151005/ | wc -l
13106

And some random websites state that VFAT (which I believe indicates FAT32)
has a low limit of files in a directory:

http://superuser.com/questions/446282/max-files-per-directory-on-ntfs-vol-
vs-fat32

------------------------------------------------------------------------

This question remains the same:

Is there are a good reason why duplicity is storing all files in 1
directory?
```

Story points: 6.0
Major Storage Space Use After Moving Files (lp:#1502478)

[Original report](https://bugs.launchpad.net/bugs/1502478) created by **Christoph Michelbach (hj7-c)**
```
I had a suspicion that Deja Dup saves files again after they have been
moved to a different location for some time. Since I now had to move my
pictures and some documents, I tested it:

I made a backup via Deja Dup, looked how much storage space the backup
takes by now, moved what I wanted to move to where I wanted to move it to,
made another backup, and looked how much space it takes up now.

So I started out at 38.2 GB and the backup now uses 46.3 GB. The difference
of 8.1 GB also is the size of the stuff I moved.

This behavior takes up a lot of storage space unnecessarily and could be
avoided by identifying a file by its hash.


$ dpkg-query -W deja-dup duplicity
deja-dup        32.0-0ubuntu5
duplicity       0.7.01-1ubuntu1
```

Story points: 6.0
SSLError: [Errno bad handshake] [('SSL routines', 'SSL3_GET_SERVER_CERTIFICATE', 'certificate verify failed')] (lp:#1498165)

[Original report](https://bugs.launchpad.net/bugs/1498165) created by **Jorman Franzini (jorman-franzini)**
```
Hi, I've some problem on duplicity run, my config is:
Using installed duplicity version 0.7.05, python 2.7.3, gpg 1.4.7 (Home:
~/.gnupg), awk 'GNU Awk 4.0.1', grep 'grep (GNU grep) 2.12', bash
'3.2.54(1)-release (i686-unknown-linux-gnu)'.

And this's the log for the run:
Traceback (most recent call last):
  File "/opt/bin/duplicity", line 1525, in <module>
    with_tempdir(main)
  File "/opt/bin/duplicity", line 1519, in with_tempdir
    fn()
  File "/opt/bin/duplicity", line 1357, in main
    action = commandline.ProcessCommandLine(sys.argv[1:])
  File "/opt/lib/python2.7/site-packages/duplicity/commandline.py", line
1103, in ProcessCommandLine
    backup, local_pathname = set_backend(args[0], args[1])
  File "/opt/lib/python2.7/site-packages/duplicity/commandline.py", line
994, in set_backend
    globals.backend = backend.get_backend(bend)
  File "/opt/lib/python2.7/site-packages/duplicity/backend.py", line 223,
in get_backend
    obj = get_backend_object(url_string)
  File "/opt/lib/python2.7/site-packages/duplicity/backend.py", line 209,
in get_backend_object
    return factory(pu)
  File "/opt/lib/python2.7/site-
packages/duplicity/backends/onedrivebackend.py", line 90, in __init__
    self.initialize_oauth2_session()
  File "/opt/lib/python2.7/site-
packages/duplicity/backends/onedrivebackend.py", line 129, in
initialize_oauth2_session
    user_info_response = self.http_client.get(self.API_URI + 'me')
  File "/opt/local/lib/python2.7/site-packages/requests/sessions.py", line
477, in get
    return self.request('GET', url, **kwargs)
  File "/opt/local/lib/python2.7/site-
packages/requests_oauthlib/oauth2_session.py", line 287, in request
    token = self.refresh_token(self.auto_refresh_url)
  File "/opt/local/lib/python2.7/site-
packages/requests_oauthlib/oauth2_session.py", line 250, in refresh_token
    timeout=timeout, verify=verify)
  File "/opt/local/lib/python2.7/site-packages/requests/sessions.py", line
508, in post
    return self.request('POST', url, data=data, json=json, **kwargs)
  File "/opt/local/lib/python2.7/site-
packages/requests_oauthlib/oauth2_session.py", line 303, in request
    headers=headers, data=data, **kwargs)
  File "/opt/local/lib/python2.7/site-packages/requests/sessions.py", line
465, in request
    resp = self.send(prep, **send_kwargs)
  File "/opt/local/lib/python2.7/site-packages/requests/sessions.py", line
573, in send
    r = adapter.send(request, **kwargs)
  File "/opt/local/lib/python2.7/site-packages/requests/adapters.py", line
431, in send
    raise SSLError(e, request=request)
SSLError: [Errno bad handshake] [('SSL routines',
'SSL3_GET_SERVER_CERTIFICATE', 'certificate verify failed')]

Any idea?

J
```

Story points: 6.0
wishlist: 	Please support Amazon's new Standard-IA storage option (lp:#1497487)

[Original report](https://bugs.launchpad.net/bugs/1497487) created by **az (az-debian)**
```
this is a forward of debian bug 799237 which lives over there:
http://bugs.debian.org/799237

the original submitter requested the following feature amendment:
---quote---
Amazon just announced a new storage option, "Standard - Infrequently
Accessed", with pricing that makes sense for storing backups.  Please
consider adding a duplicity option to support it, similar to the
existing --s3-use-rrs option to use Reduced Redundancy storage.

It might make sense for the new option to support passing the name of a
storage class, rather than introducing a new boolean option, to make it
easier to add more storage classes in the future.
---quote---
```

Story points: 12.0
Add option for volume numbering width (lp:#1496153)

[Original report](https://bugs.launchpad.net/bugs/1496153) created by **Dionisio E Alonso (baco)**
```
It would be nice to have the option to set the volume numbering width
(number of digits for volXXX) in order to generate names like duplicity-
full-...-vol01.difftar... or ...-vol001... so they became ordered when
listed sorted by name.
```
Original tags: enhacement

Story points: 6.0
Wishlist: Amazon Cloud Drive backend (lp:#1493632)

[Original report](https://bugs.launchpad.net/bugs/1493632) created by **Elan Kugelmass (epkugelmass)**
```
I'd like to see a backend for Amazon Cloud Drive included with duplicity.

Amazon recently changed their pricing strategy to be much more aggressive.
They are offering unlimited storage for about $60/year. They also recently
exposed a REST api for the service
(https://developer.amazon.com/public/apis/experience/cloud-
drive/content/restful-api). ACS is presumably powered by S3 -- and if the
APIs are similar, this might be a relatively easy (and much appreciated!)
backend to implement.
```
Original tags: wishlist

Story points: 20.0
Pydrive broken resume: not dealing with duplicate filenames (lp:#1489145)

[Original report](https://bugs.launchpad.net/bugs/1489145) created by **mfitz (mfitz)**
```
Google drive supports two files with the same name in the same place. This
isn't being handled currently.

Resume from interrupted full backup does not currently work, here are some
reasons:

* On resume, it re-uploads last file in manifest without deleting it from
the server beforehand, resulting in two files of the same name. It attempts
to add the file to an internal python list/dictionary and crashes.
* On occasion, the same file is added twice. On reading the server, it
attempts to add the file to an internal python list/dictionary and crashes.

Workarounds:
* On resume, always delete last file. Manifest should always contain more
files.
* When duplicate files are found "in the middle", duplicity will crash,
giving the duplicate filename in the array printed (last element). Do this
over and over until all dupes are gone.

Duplicity 7.04
Python 2.7.10
```

Story points: 6.0
Pydrive: tabs in google_drive_settings (lp:#1485756)

[Original report](https://bugs.launchpad.net/bugs/1485756) created by **mfitz (mfitz)**
```
Duplicity version:7.04

"Google drive settings file" as written in the man page doesn't make clear
that the file is yaml and therefore cannot contain tab characters.

Currently, if the settings file contains nonsense such as a tab character,
it is skipped. An unrelated error to do with json files will be displayed
instead because all the settings are ignored.
```

Story points: 6.0
Progress not working with many backends (lp:#1482841)

[Original report](https://bugs.launchpad.net/bugs/1482841) created by **Artur Bodera (abodera)**
```
The --progress flag and progress bar seem to be broken with a lot of
backends.
So far I've tested CF+Hubic and onedrive, both behave the same way. With
--verbosity debug I can see that subsequent volumes are being sent to
backend for transfer, backend keeps transferring them, but the progress bar
after 8 hours of work looks the same:

0.0KB 08:00:00 [0.0B/s] [>                                        ] 0% ETA
Stalled!
0.0KB 08:00:03 [0.0B/s] [>                                        ] 0% ETA
Stalled!
0.0KB 08:00:06 [0.0B/s] [>                                        ] 0% ETA
Stalled!
0.0KB 08:00:09 [0.0B/s] [>                                        ] 0% ETA
Stalled!

It never moves.

I understand that some backends might not be good at reporting speed or
file transfer progress, but I don't see why the progress bar would not be
updated at least after each volume has been transferred ( no. MB
transferred / no MB total to transfer = progress).
```

Story points: 162.0