giseldo/neodataset huggingface dataset:
backup process to Amazon S3 crashes after aborted  previous attempt (lp:#909019)

[Original report](https://bugs.launchpad.net/bugs/909019) created by **Andrew Burdyug (buran83)**
```
The backup process to Amazon S3 crashes after aborted  previous attempt,

duplicity reports about problem with my secret gpg key,

but there is no problem with my gpg keys and if I delete
~/.cache/duplicity/1236317e04b0824d1d84cc5d3605afa5/*part, then new full
backup start as usual.

Seems as a bug with gpg signed and partial aborted backups.

duplicity 0.6.17
```

Story points: 6.0
s3 upload speed: periodically drops to zero (lp:#908429)

[Original report](https://bugs.launchpad.net/bugs/908429) created by **Andrei Pozolotin (andrei-pozolotin)**
```
the following invocation

duplicity \
  --volsize $VOLUME_SIZE \
  --s3-use-new-style \
  --verbosity info \
  --asynchronous-upload \
  --include-globbing-filelist $INCLUDE \
  --exclude-globbing-filelist $EXCLUDE \
  $SOURCE $TARGET

produces attached "upload speed drops"

despite "--asynchronous-upload"

###################################

user1@wks002:~/.duplicity$ duplicity --version
duplicity 0.6.17

user1@wks002:~/.duplicity$ uname -a
Linux wks002 3.0.0-14-generic-pae #23-Ubuntu SMP Mon Nov 21 22:07:10 UTC
2011 i686 i686 i386 GNU/Linux
```

Story points: 6.0
s3 upload speed: duplicity vs s3cmd (lp:#908424)

[Original report](https://bugs.launchpad.net/bugs/908424) created by **Andrei Pozolotin (andrei-pozolotin)**
```
1) I use comcast cable internet to access s3;

2) my reference upload speed as measured by
http://www.speakeasy.net/speedtest/
Download Speed: 25486 kbps (3185.8 KB/sec transfer rate)
Upload Speed: 4211 kbps (526.4 KB/sec transfer rate)

3) using s3cmd
http://s3tools.org/s3cmd
I am able to get sustained s3 upload speed close to 500 KB/sec

4) using duplicity

duplicity \
  --volsize $VOLUME_SIZE \
  --s3-use-new-style \
  --verbosity info \
  --asynchronous-upload \
  --include-globbing-filelist $INCLUDE \
  --exclude-globbing-filelist $EXCLUDE \
  $SOURCE $TARGET

I get only about 250 KB/sec

5) I tried various options, volume sizes, etc
still, I get only about 250 KB/sec no matter what;

any suggestions, please?

thank you.

###################################

user1@wks002:~/.duplicity$ duplicity --version
duplicity 0.6.17

user1@wks002:~/.duplicity$ uname -a
Linux wks002 3.0.0-14-generic-pae #23-Ubuntu SMP Mon Nov 21 22:07:10 UTC
2011 i686 i686 i386 GNU/Linux
```

Story points: 6.0
crash with --s3-use-multiprocessing (lp:#908417)

[Original report](https://bugs.launchpad.net/bugs/908417) created by **Andrei Pozolotin (andrei-pozolotin)**
```
the following invocation

duplicity \
  --volsize $VOLUME_SIZE \
  --s3-use-new-style \
  --verbosity info \
  --asynchronous-upload \
  --s3-use-multiprocessing \
  --include-globbing-filelist $INCLUDE \
  --exclude-globbing-filelist $EXCLUDE \
  $SOURCE $TARGET

works fine if I remove --s3-use-multiprocessing
but it blows up with exception otherwise:

user1@wks002:~/.duplicity$ ./save.sh
Using archive dir:
/home/user1/.cache/duplicity/8f7a2bc069fd6f70a8dccbf1ce8eb68a
Using backup name: 8f7a2bc069fd6f70a8dccbf1ce8eb68a
Import of duplicity.backends.rsyncbackend Succeeded
Import of duplicity.backends.ftpsbackend Succeeded
Import of duplicity.backends.webdavbackend Succeeded
Import of duplicity.backends.gdocsbackend Succeeded
Import of duplicity.backends.ftpbackend Succeeded
Import of duplicity.backends.sshbackend Succeeded
Import of duplicity.backends.imapbackend Succeeded
Import of duplicity.backends.cloudfilesbackend Succeeded
Import of duplicity.backends.botobackend Failed: name 'sys' is not defined
Import of duplicity.backends.tahoebackend Succeeded
Import of duplicity.backends.hsibackend Succeeded
Import of duplicity.backends.localbackend Succeeded
Import of duplicity.backends.u1backend Succeeded
Import of duplicity.backends.giobackend Succeeded
Using temporary directory /tmp/duplicity-IKgSDI-tempdir
User error detail: Traceback (most recent call last):
  File "/usr/bin/duplicity", line 1377, in <module>
    with_tempdir(main)
  File "/usr/bin/duplicity", line 1370, in with_tempdir
    fn()
  File "/usr/bin/duplicity", line 1221, in main
    action = commandline.ProcessCommandLine(sys.argv[1:])
  File "/usr/lib/python2.6/dist-packages/duplicity/commandline.py", line
996, in ProcessCommandLine
    backup, local_pathname = set_backend(args[0], args[1])
  File "/usr/lib/python2.6/dist-packages/duplicity/commandline.py", line
889, in set_backend
    globals.backend = backend.get_backend(bend)
  File "/usr/lib/python2.6/dist-packages/duplicity/backend.py", line 154,
in get_backend
    raise UnsupportedBackendScheme(url_string)
UnsupportedBackendScheme: scheme not supported in url: s3+http://archive-
duplicity/wks002

UnsupportedBackendScheme: scheme not supported in url: s3+http://archive-
duplicity/wks002


########################

user1@wks002:~/.duplicity$ duplicity --version
duplicity 0.6.17

user1@wks002:~/.duplicity$ uname -a
Linux wks002 3.0.0-14-generic-pae #23-Ubuntu SMP Mon Nov 21 22:07:10 UTC
2011 i686 i686 i386 GNU/Linux
```

Story points: 16.0
Signature Files Double in size upon restart (lp:#907669)

[Original report](https://bugs.launchpad.net/bugs/907669) created by **jpsb (jpsb)**
```
If a backup fails or is aborted the signature files (local) double in size
before resuming uploads, this is pretty tragic when trying to do a large
(140GB) backup to cloudfiles as the signature file can easily go from 5GB
to 11GB uncompressed and then be impossible to upload.
```

Story points: 6.0
Misleading 'last full backup' when restoring (lp:#906995)

[Original report](https://bugs.launchpad.net/bugs/906995) created by **CiaranG (ciarang)**
```
When restoring (using version 0.6.13), I am being told this:

  Last full backup date: Tue Dec 13 10:46:14 2011

However, that's not the case. That's the last full backup in the primary
chain, but there are secondary ones that are older. Fortunately regardless
of that output, it looks like Duplicity can see the older backups, and
successfully restores from that when asked to (via --restore-time).
(However, there's no way of knowing it's worked, other than recognising
that the restored output is as old as expected - duplicity says nothing
else at all after the above output).

Full collection status corresponding to the above:


Found 1 secondary backup chain.
Secondary chain 1 of 1:
-------------------------
Chain start time: Sun Nov 27 12:54:20 2011
Chain end time: Sun Nov 27 12:54:20 2011
Number of contained backup sets: 1
Total number of contained volumes: 25
 Type of backup set:                            Time:      Num volumes:
                Full         Sun Nov 27 12:54:20 2011                25
-------------------------

Found primary backup chain with matching signature chain:
-------------------------
Chain start time: Tue Dec 13 10:46:14 2011
Chain end time: Tue Dec 20 03:41:31 2011
Number of contained backup sets: 8
Total number of contained volumes: 28
 Type of backup set:                            Time:      Num volumes:
                Full         Tue Dec 13 10:46:14 2011                21
         Incremental         Wed Dec 14 03:42:50 2011                 1
         Incremental         Thu Dec 15 03:42:22 2011                 1
         Incremental         Fri Dec 16 03:41:50 2011                 1
         Incremental         Sat Dec 17 03:42:28 2011                 1
         Incremental         Sun Dec 18 03:41:56 2011                 1
         Incremental         Mon Dec 19 03:41:53 2011                 1
         Incremental         Tue Dec 20 03:41:31 2011                 1
-------------------------
No orphaned or incomplete backup sets found.
```

Story points: 6.0
duplicity crashing with an Assertion error when trying to restore (lp:#900600)

[Original report](https://bugs.launchpad.net/bugs/900600) created by **Chris Stankaitis (cstankaitis)**
```
I am trying to restore a backup... duplicity keeps on crashing out with an
Assertion Error please help

OS: RHEL6
Duplicity ver: duplicity-0.6.14-1.el6.x86_64
Python: python-2.6.5-3.el6.x86_64

Here is the command I am using.

[root@backup1.tor.fmpub.net restoretemp]# duplicity --no-encryption -t
"2011/11/28" --archive-dir "/backup/restoretemp" --tempdir "/var/tmp" -v6
file:///backup/backup2.tor.fmpub.net/backup/xtrabackup-db-backup/bt-3306/
/backup/restoretemp/bt-restore
Using archive dir: /backup/restoretemp/b6dfbc00e137c1d3f4db133984ed9231
Using backup name: b6dfbc00e137c1d3f4db133984ed9231
Import of duplicity.backends.imapbackend Succeeded
Import of duplicity.backends.giobackend Failed: No module named gio
Import of duplicity.backends.u1backend Succeeded
Import of duplicity.backends.cloudfilesbackend Succeeded
Import of duplicity.backends.rsyncbackend Succeeded
Import of duplicity.backends.webdavbackend Succeeded
Import of duplicity.backends.ftpsbackend Succeeded
Import of duplicity.backends.tahoebackend Succeeded
Import of duplicity.backends.ftpbackend Succeeded
Import of duplicity.backends.botobackend Succeeded
Import of duplicity.backends.sshbackend Succeeded
Import of duplicity.backends.localbackend Succeeded
Import of duplicity.backends.hsibackend Succeeded
Main action: restore
================================================================================
duplicity 0.6.14 (June 18, 2011)
Args: /usr/bin/duplicity --no-encryption -t 2011/11/28 --archive-dir
/backup/restoretemp --tempdir /var/tmp -v6
file:///backup/backup2.tor.fmpub.net/backup/xtrabackup-db-backup/bt-3306/
/backup/restoretemp/bt-restore
Linux backup1.tor.fmpub.net 2.6.32-71.7.1.el6.x86_64 #1 SMP Wed Oct 27
03:44:59 EDT 2010 x86_64 x86_64
/usr/bin/python 2.6.5 (r265:79063, Jul 14 2010, 11:36:05)
[GCC 4.4.4 20100630 (Red Hat 4.4.4-10)]
================================================================================
Using temporary directory /var/tmp/duplicity-7maMxv-tempdir
Temp has 108288081920 available, backup will use approx 34078720.
Local and Remote metadata are synchronized, no sync needed.
Traceback (most recent call last):
  File "/usr/bin/duplicity", line 1311, in <module>
    with_tempdir(main)
  File "/usr/bin/duplicity", line 1304, in with_tempdir
    fn()
  File "/usr/bin/duplicity", line 1184, in main
    globals.archive_dir).set_values()
  File "/usr/lib64/python2.6/site-packages/duplicity/collections.py", line
692, in set_values
    backup_chains)
  File "/usr/lib64/python2.6/site-packages/duplicity/collections.py", line
705, in set_matched_chain_pair
    sig_chains = sig_chains and self.get_sorted_chains(sig_chains)
  File "/usr/lib64/python2.6/site-packages/duplicity/collections.py", line
918, in get_sorted_chains
    assert len(chain_list) == 2
AssertionError

Thank You
```

Story points: 6.0
Wrong German Translation (lp:#897355)

[Original report](https://bugs.launchpad.net/bugs/897355) created by **Allo (allo)**
```
In the filename log (when verbosity is high enough), there is "Ein
/some/path", which seems to be wrong. I think the original was "A
/some/path", and "Ein(e)" is the german unspecified article like the
english a/an.
```
Original tags: german translation

Story points: 12.0
man page file permissions: 600 (lp:#897147)

[Original report](https://bugs.launchpad.net/bugs/897147) created by **SanskritFritz (sanskritfritz+launchpad)**
```
Duplicity Version        : 0.6.17
The man file permissions have been changed:
ls -l /usr/share/man/man1/dupl*
-rw------- 1 root root  13K 2011-11-25 20:20
/usr/share/man/man1/duplicity.1.gz

The result is that non root users are unable to read the manpage for
duplicity.

The setup in archlinux is as follows:
python2 setup.py install --root="$pkgdir" --optimize=1
```
Original tags: man

Story points: 12.0
WebDAV backend handles 204 status code as a failure (lp:#888301)

[Original report](https://bugs.launchpad.net/bugs/888301) created by **Hugh Eaves (hugh-hugheaves)**
```
Duplicity Version: 6.15, 6.16, 7.0
Ubuntu 10.04 LTS, Apache 2.2 with mod_dav
Python 2.7.2+ (default, Oct  4 2011, 20:06:09)

When a backup is interrupted and then resumed later, duplicity will
(correctly) attempt to re-create and overwrite the last volume created by
the interrupted backup. However, when overwriting an existing file using a
WebDAV PUT, Apache 2.2 returns a '204 - No Content' status instead of '201
- Created'. Even though the file uploaded correctly, the current
webdavbackend.py considers anything but a "201" to be a failure.

http://bazaar.launchpad.net/~duplicity-
team/duplicity/0.7-series/view/head:/duplicity/backends/webdavbackend.py#L252
```

Story points: 12.0
UbuntuOne not listed in command line help (lp:#887355)

[Original report](https://bugs.launchpad.net/bugs/887355) created by **P Fudd (g-ubuntu-com)**
```
Typing 'duplicity --help' does not list 'u1://host/volume_path'
'u1+http://volume_path' in version 0.6.16.

Duplicity version: 0.6.16
Python version: 2.7
OS Distro and version: Fedora 14
Target: Ubuntu One
Log output: ha
```

Story points: 6.0
Wishlist: Need for more details on which incremental backup is restored (lp:#886871)

[Original report](https://bugs.launchpad.net/bugs/886871) created by **Olivier Berger (olivierberger)**
```
It would be great to have duplicity restore command messages add a more
descriptive message mentioning which increment was restored and not only
the reference to its full backup.

As it is now, it looks like only the old full backup was restored.

See http://lists.nongnu.org/archive/html/duplicity-
talk/2011-11/msg00030.html for more details
```

Story points: 6.0
S3 multichunk support uploads too much data (lp:#885513)

[Original report](https://bugs.launchpad.net/bugs/885513) created by **Michael Terry (mterry)**
```
If the volume being uploaded is not perfectly divisible by the S3
multichunk size, duplicity will end up uploading too much data.

This appears to be because of the following code in botobackend.py:

            chunks = bytes / chunk_size
            if (bytes % chunk_size):
                chunks += 1
...
        for n in range(chunks):
            params = {
...
                'bytes': chunk_size,
```

Story points: 8.0
cfbackend should use the retry decorator (lp:#884345)

[Original report](https://bugs.launchpad.net/bugs/884345) created by **Scott Severance (scott.severance)**
```
I'm backing up to Rackspace, and I have quite a large backup set. Often
when backing up, some sort of network exception gets raised. Sometimes,
it's a connection timeout. Other times it's an SSL error. There are
probably others, too, that I don't remember at the moment. Sometimes the
error will occur early in the backup process. Other times it'll be near the
end.

Of course, all these error conditions are transient, yet DD just reports a
Backend exception and gives up. Instead, it should retry a number of times,
especially if it has already connected in the current session. Networks are
unreliable, and DD doesn't seem to realize this.

I'm currently using Ubuntu 11.10 with deja-dup 20.1-0ubuntu0.1 and
duplicity 0.6.15-0ubuntu2. However, this problem has been going on for a
long time and a number of versions.
```

Story points: 22.0
Backup fails after initially scanning older backups (lp:#879957)

[Original report](https://bugs.launchpad.net/bugs/879957) created by **Neil Robinson (halfhaggis+)**
```
This problem has only surfaced since upgrading to 11.10

Expected result:
Backup backs up files to external hard drive as it has previously done
flawlessly.

Action taken:
Run deja-dup.
Select make new backup.
Scanning starts, but stops and deja-dup reports "Backup Failed."

Gives this error:
Failed to read /tmp/duplicity-Xxfwll-tempdir/mktemp-8Ylyy0-1: (<type
'exceptions.IOError'>, IOError('CRC check failed 0x96cdfab !=
0x8652a9f7L',), <traceback object at 0x86fcb44>)

--

Incidentally, it restoring backups from the previous backups results in a
similar error.
I haven't tried restoring anything using duplicity directly.

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: deja-dup 20.1-0ubuntu0.1
ProcVersionSignature: Ubuntu 3.0.0-12.20-generic 3.0.4
Uname: Linux 3.0.0-12-generic i686
ApportVersion: 1.23-0ubuntu3
Architecture: i386
Date: Sat Oct 22 15:08:13 2011
InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release i386 (20100429)
SourcePackage: deja-dup
UpgradeStatus: Upgraded to oneiric on 2011-10-16 (5 days ago)
```
Original tags: apport-bug i386 oneiric running-unity

Story points: 6.0
Backing up fails with 'IOError CRC check failed'. (lp:#875676)

[Original report](https://bugs.launchpad.net/bugs/875676) created by **Michael Terry (mterry)**
```
For 4 days déjà dup hasn't been able to perform a backup. It fails with the
error

Failed to read /tmp/duplicity-lJcUDl-tempdir/mktemp-o4LYSJ-1: (<type
'exceptions.IOError'>, IOError('CRC check failed 0x8434f7d2L !=
0x3d503338L',), <traceback object at 0x9fe0554>)

There is another similar bug #676767 where deleting ~/.cache/deja-dup
helps. In this case it doesn't.

I'm quite certain that my backup drive isn't corrupted. (It's a raid5.) I'd
be happy to provide any additional information needed.

----------

System information:
Ubuntu 11.10
deja-dup 20.0-0ubuntu3
duplicity 0.6.15-0ubuntu2

Logs:
deja-dup.log: http://pastie.org/2705320
deja-dup.gsettings: http://pastie.org/2705322
```
Original tags: xenial

Story points: 136.0
duplicity creates huge backup archives (lp:#873164)

[Original report](https://bugs.launchpad.net/bugs/873164) created by **Anders Aagaard (aagaande)**
```
Runnning this command:
# duplicity --no-encryption --volsize 25 --full-if-older-than 1M
--s3-european-buckets --s3-use-new-style /path/ s3+http://path

# ls -lh ./.cache/duplicity/cb16c6c2ab88f146c07ca64f59318183/
total 73G
-rw------- 1 root root 2.1M 2011-10-11 21:52 duplicity-
full.20110919T174252Z.manifest.part
-rw------- 1 root root  31G 2011-10-11 22:46 duplicity-full-
signatures.20110919T174252Z.sigtar.gz
-rw------- 1 root root  43G 2011-10-11 21:52 duplicity-full-
signatures.20110919T174252Z.sigtar.part

Most of my duplicity backups work fine, but in this directory it's not
splitting the archives properly.

duplicity 0.6.14 ubuntu 10.10, python 2.6.6
```

Story points: 12.0
IMAPS target doesn't work on Centos 5.6 (lp:#859054)

[Original report](https://bugs.launchpad.net/bugs/859054) created by **Alexander Akimov (aleksander-akimow)**
```
Using installed duplicity version 0.6.14, python 2.4.3, gpg 1.4.5 (Home:
~/.gnupg), awk 'GNU Awk 3.1.5', bash '3.2.25(1)-release (i686-redhat-linux-
gnu)'.
 I get the following error:
--- Start running command BKP at 20:27:43.776 ---
Traceback (most recent call last):
  File "/usr/bin/duplicity", line 1311, in ?
    with_tempdir(main)
  File "/usr/bin/duplicity", line 1304, in with_tempdir
    fn()
  File "/usr/bin/duplicity", line 1156, in main
    action = commandline.ProcessCommandLine(sys.argv[1:])
  File "/usr/lib/python2.4/site-packages/duplicity/commandline.py", line
938, in ProcessCommandLine
    backup, local_pathname = set_backend(args[0], args[1])
  File "/usr/lib/python2.4/site-packages/duplicity/commandline.py", line
831, in set_backend
    globals.backend = backend.get_backend(bend)
  File "/usr/lib/python2.4/site-packages/duplicity/backend.py", line 155,
in get_backend
    return _backends[pu.scheme](pu)
  File "/usr/lib/python2.4/site-
packages/duplicity/backends/imapbackend.py", line 66, in __init__
    self._resetConnection()
  File "/usr/lib/python2.4/site-
packages/duplicity/backends/imapbackend.py", line 86, in _resetConnection
    self._conn = cl(imap_server, 993)
  File "/usr/lib/python2.4/imaplib.py", line 1101, in __init__
    IMAP4.__init__(self, host, port)
  File "/usr/lib/python2.4/imaplib.py", line 181, in __init__
    self.welcome = self._get_response()
  File "/usr/lib/python2.4/imaplib.py", line 876, in _get_response
    resp = self._get_line()
  File "/usr/lib/python2.4/imaplib.py", line 969, in _get_line
    line = self.readline()
  File "/usr/lib/python2.4/imaplib.py", line 1135, in readline
    char = self.sslobj.read(1)
sslerror: The read operation timed out

20:28:14.499 Task 'BKP' failed with exit code '30'.
--- Finished state FAILED 'code 30' at 20:28:14.499 - Runtime 00:00:30.722
---
```

Story points: 6.0
SElinux xattrs support for duplicity (lp:#829405)

[Original report](https://bugs.launchpad.net/bugs/829405) created by **jo akweb (jo-8)**
```
(This is more a feature request than a bug report - I hope that's ok.)

As of duplicity-0.6.14, it doesn't seem to support SElinux file attributes.
Without these attributes preserved, it can be virtually impossible to
restore a working Redhat or CentOS system, where by default SElinux is
activated.

It should be possible to extend duplicity to support these attributes,
because rsync provides an command line switch (--xattrs) for this.
```

Story points: 26.0
Always forces full backup (lp:#829198)

[Original report](https://bugs.launchpad.net/bugs/829198) created by **Michal Čihař (nijel)**
```
I'm running daily incremental backups and monthly full ones. Since upgrade
to 0.6.14 (it might also appear in 0.6.13, because I'm not sure if I did
use that one), duplicity always does full backup:

Reading globbing filelist /etc/duplicity.list
Synchronizing remote metadata to local cache...
Deleting local
/var/cache/duplicity/57cfdb6f20a4104d181d228fc19db339/duplicity-full-
signatures.20110818T033800Z.sigtar.gz (not authoritative at backend).
Deleting local
/var/cache/duplicity/57cfdb6f20a4104d181d228fc19db339/duplicity-
full.20110818T033800Z.manifest (not authoritative at backend).
Last full backup date: none
No signatures found, switching to full backup.

The collection-status reports all previous full backups correctly and
restore from them works also fine.

Files which did exist on backend by time the backup was run:

duplicity-full-signatures.20110819T044314Z.sigtar.gpg  duplicity-
full.20110819T044314Z.vol1.difftar.gpg
duplicity-full.20110819T044314Z.manifest.gpg

The problem seems to be in fact that it no longer handles path
scp://backup@backup.home.cihar.com//volume1/backup/ as absolute on the
backup server:

State = sftp, Before = 'Connected to backup.home.cihar.com.'
sftp command: 'mkdir ""'
State = sftp, Before = 'mkdir ""
Couldn't create directory: Failure'
sftp command: 'cd ""'
State = sftp, Before = 'cd ""'
sftp command: 'mkdir ""'
State = sftp, Before = 'mkdir ""
Couldn't create directory: Failure'
sftp command: 'cd ""'
State = sftp, Before = 'cd ""'
sftp command: 'mkdir "volume1"'
State = sftp, Before = 'mkdir "volume1"
Couldn't create directory: Failure'
sftp command: 'cd "volume1"'
State = sftp, Before = 'cd "volume1"'
sftp command: 'mkdir "backup"'
State = sftp, Before = 'mkdir "backup"
Couldn't create directory: Failure'
sftp command: 'cd "backup"'
State = sftp, Before = 'cd "backup"'
sftp command: 'mkdir ""'
State = sftp, Before = 'mkdir ""
Couldn't create directory: Failure'
sftp command: 'cd ""'
State = sftp, Before = 'cd ""'
sftp command: 'mkdir "jabber"'
State = sftp, Before = 'mkdir "jabber"
Couldn't create directory: Failure'
sftp command: 'cd "jabber"'
State = sftp, Before = 'cd "jabber"'
sftp command: 'ls -1'
State = sftp, Before = 'ls -1'
State = sftp, Before = 'quit'
```

Story points: 18.0