Merge pull request #5212 from ThomasWaldmann/rel1112

release 1.1.12

Vagrantfile

@@ -7,13 +7,6 @@ $cpus = Integer(ENV.fetch('VMCPUS', '4'))  # create VMs with that many cpus
 $xdistn = Integer(ENV.fetch('XDISTN', '4'))  # dispatch tests to that many pytest workers
 $wmem = $xdistn * 256  # give the VM additional memory for workers [MB]
 
-def packages_prepare_wheezy
-  return <<-EOF
-      # debian 7 wheezy does not have lz4, but it is available from wheezy-backports:
-      echo "deb http://http.debian.net/debian wheezy-backports main" > /etc/apt/sources.list.d/wheezy-backports.list
-  EOF
-end
-
 def packages_debianoid(user)
   return <<-EOF
     export DEBIAN_FRONTEND=noninteractive
@@ -483,40 +476,6 @@ Vagrant.configure(2) do |config|
     b.vm.provision "run tests", :type => :shell, :privileged => false, :inline => run_tests("jessie64")
   end
 
-  config.vm.define "wheezy32" do |b|
-    b.vm.box = "debian7-i386"
-    b.vm.provider :virtualbox do |v|
-      v.memory = 768 + $wmem
-    end
-    b.vm.provision "fs init", :type => :shell, :inline => fs_init("vagrant")
-    b.vm.provision "packages prepare wheezy", :type => :shell, :inline => packages_prepare_wheezy
-    b.vm.provision "packages debianoid", :type => :shell, :inline => packages_debianoid("vagrant")
-    b.vm.provision "install pyenv", :type => :shell, :privileged => false, :inline => install_pyenv("wheezy32")
-    b.vm.provision "install pythons", :type => :shell, :privileged => false, :inline => install_pythons("wheezy32")
-    b.vm.provision "build env", :type => :shell, :privileged => false, :inline => build_pyenv_venv("wheezy32")
-    b.vm.provision "install borg", :type => :shell, :privileged => false, :inline => install_borg(true)
-    b.vm.provision "install pyinstaller", :type => :shell, :privileged => false, :inline => install_pyinstaller()
-    b.vm.provision "build binary with pyinstaller", :type => :shell, :privileged => false, :inline => build_binary_with_pyinstaller("wheezy32")
-    b.vm.provision "run tests", :type => :shell, :privileged => false, :inline => run_tests("wheezy32")
-  end
-
-  config.vm.define "wheezy64" do |b|
-    b.vm.box = "debian7-amd64"
-    b.vm.provider :virtualbox do |v|
-      v.memory = 1024 + $wmem
-    end
-    b.vm.provision "fs init", :type => :shell, :inline => fs_init("vagrant")
-    b.vm.provision "packages prepare wheezy", :type => :shell, :inline => packages_prepare_wheezy
-    b.vm.provision "packages debianoid", :type => :shell, :inline => packages_debianoid("vagrant")
-    b.vm.provision "install pyenv", :type => :shell, :privileged => false, :inline => install_pyenv("wheezy64")
-    b.vm.provision "install pythons", :type => :shell, :privileged => false, :inline => install_pythons("wheezy64")
-    b.vm.provision "build env", :type => :shell, :privileged => false, :inline => build_pyenv_venv("wheezy64")
-    b.vm.provision "install borg", :type => :shell, :privileged => false, :inline => install_borg(true)
-    b.vm.provision "install pyinstaller", :type => :shell, :privileged => false, :inline => install_pyinstaller()
-    b.vm.provision "build binary with pyinstaller", :type => :shell, :privileged => false, :inline => build_binary_with_pyinstaller("wheezy64")
-    b.vm.provision "run tests", :type => :shell, :privileged => false, :inline => run_tests("wheezy64")
-  end
-
   # OS X
   config.vm.define "darwin64" do |b|
     b.vm.box = "macos-sierra"

docs/changes.rst

@@ -217,8 +217,8 @@ The best check that everything is ok is to run a dry-run extraction::
 Changelog
 =========
 
-Version 1.1.12 (not released yet)
----------------------------------
+Version 1.1.12 (2020-06-06)
+---------------------------
 
 Compatibility notes:
 
@@ -264,6 +264,8 @@ Other changes:
   improve macOS builds.
 - tests: test_delete_force: avoid sporadic test setup issues, #5196
 - misc. vagrant fixes
+- the binary for macOS is now built on macOS 10.12
+- the binaries for Linux are now built on Debian 8 "Jessie", #3761
 - docs:
 
   - PlaceholderError not printed as JSON, #4073

docs/installation.rst

@@ -92,10 +92,10 @@ Standalone Binary
 |project_name| x86/x64 amd/intel compatible binaries (generated with `pyinstaller`_)
 are available on the releases_ page for the following platforms:
 
-* **Linux**: glibc >= 2.13 (ok for most supported Linux releases).
+* **Linux**: glibc >= 2.19 (ok for most supported Linux releases).
   Older glibc releases are untested and may not work.
-* **Mac OS X**: 10.10 (does not work with older OS X releases)
-* **FreeBSD**: 10.2 (unknown whether it works for older releases)
+* **Mac OS X**: 10.12 (unknown whether it works for older releases)
+* **FreeBSD**: 10.3 (unknown whether it works for older releases)
 
 ARM binaries are built by Johann Bauer, see: https://borg.bauerj.eu/
 

docs/man/borg-benchmark-crud.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH BORG-BENCHMARK-CRUD 1 "2020-03-07" "" "borg backup tool"
+.TH BORG-BENCHMARK-CRUD 1 "2020-06-06" "" "borg backup tool"
 .SH NAME
 borg-benchmark-crud \- Benchmark Create, Read, Update, Delete for archives.
 .

docs/man/borg-benchmark.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH BORG-BENCHMARK 1 "2020-03-07" "" "borg backup tool"
+.TH BORG-BENCHMARK 1 "2020-06-06" "" "borg backup tool"
 .SH NAME
 borg-benchmark \- benchmark command
 .

docs/man/borg-break-lock.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH BORG-BREAK-LOCK 1 "2020-03-07" "" "borg backup tool"
+.TH BORG-BREAK-LOCK 1 "2020-06-06" "" "borg backup tool"
 .SH NAME
 borg-break-lock \- Break the repository lock (e.g. in case it was left by a dead borg.
 .

docs/man/borg-change-passphrase.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH BORG-CHANGE-PASSPHRASE 1 "2020-03-07" "" "borg backup tool"
+.TH BORG-CHANGE-PASSPHRASE 1 "2020-06-06" "" "borg backup tool"
 .SH NAME
 borg-change-passphrase \- Change repository key file passphrase
 .

docs/man/borg-check.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH BORG-CHECK 1 "2020-03-07" "" "borg backup tool"
+.TH BORG-CHECK 1 "2020-06-06" "" "borg backup tool"
 .SH NAME
 borg-check \- Check repository consistency
 .
@@ -40,20 +40,20 @@ The check command verifies the consistency of a repository and the corresponding
 First, the underlying repository data files are checked:
 .INDENT 0.0
 .IP \(bu 2
-For all segments the segment magic (header) is checked
+For all segments, the segment magic header is checked.
 .IP \(bu 2
-For all objects stored in the segments, all metadata (e.g. crc and size) and
+For all objects stored in the segments, all metadata (e.g. CRC and size) and
 all data is read. The read data is checked by size and CRC. Bit rot and other
 types of accidental damage can be detected this way.
 .IP \(bu 2
-If we are in repair mode and a integrity error is detected for a segment,
-we try to recover as many objects from the segment as possible.
+In repair mode, if an integrity error is detected in a segment, try to recover
+as many objects from the segment as possible.
 .IP \(bu 2
-In repair mode, it makes sure that the index is consistent with the data
-stored in the segments.
+In repair mode, make sure that the index is consistent with the data stored in
+the segments.
 .IP \(bu 2
-If you use a remote repo server via ssh:, the repo check is executed on the
-repo server without causing significant network traffic.
+If checking a remote repo via \fBssh:\fP, the repo check is executed on the server
+without causing significant network traffic.
 .IP \(bu 2
 The repository check can be skipped using the \fB\-\-archives\-only\fP option.
 .UNINDENT
@@ -64,26 +64,24 @@ Second, the consistency and correctness of the archive metadata is verified:
 Is the repo manifest present? If not, it is rebuilt from archive metadata
 chunks (this requires reading and decrypting of all metadata and data).
 .IP \(bu 2
-Check if archive metadata chunk is present. if not, remove archive from
-manifest.
+Check if archive metadata chunk is present; if not, remove archive from manifest.
 .IP \(bu 2
 For all files (items) in the archive, for all chunks referenced by these
-files, check if chunk is present.
-If a chunk is not present and we are in repair mode, replace it with a same\-size
-replacement chunk of zeros.
-If a previously lost chunk reappears (e.g. via a later backup) and we are in
-repair mode, the all\-zero replacement chunk will be replaced by the correct chunk.
-This requires reading of archive and file metadata, but not data.
+files, check if chunk is present. In repair mode, if a chunk is not present,
+replace it with a same\-size replacement chunk of zeroes. If a previously lost
+chunk reappears (e.g. via a later backup), in repair mode the all\-zero replacement
+chunk will be replaced by the correct chunk. This requires reading of archive and
+file metadata, but not data.
 .IP \(bu 2
-If we are in repair mode and we checked all the archives: delete orphaned
-chunks from the repo.
+In repair mode, when all the archives were checked, orphaned chunks are deleted
+from the repo. One cause of orphaned chunks are input file related errors (like
+read errors) in the archive creation process.
 .IP \(bu 2
-if you use a remote repo server via ssh:, the archive check is executed on
-the client machine (because if encryption is enabled, the checks will require
-decryption and this is always done client\-side, because key access will be
-required).
+If checking a remote repo via \fBssh:\fP, the archive check is executed on the
+client machine because it requires decryption, and this is always done client\-side
+as key access is needed.
 .IP \(bu 2
-The archive checks can be time consuming, they can be skipped using the
+The archive checks can be time consuming; they can be skipped using the
 \fB\-\-repository\-only\fP option.
 .UNINDENT
 .sp
@@ -91,9 +89,8 @@ The \fB\-\-verify\-data\fP option will perform a full integrity verification (as
 checking the CRC32 of the segment) of data, which means reading the data from the
 repository, decrypting and decompressing it. This is a cryptographic verification,
 which will detect (accidental) corruption. For encrypted repositories it is
-tamper\-resistant as well, unless the attacker has access to the keys.
-.sp
-It is also very slow.
+tamper\-resistant as well, unless the attacker has access to the keys. It is also very
+slow.
 .SH OPTIONS
 .sp
 See \fIborg\-common(1)\fP for common options of Borg commands.

docs/man/borg-common.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH BORG-COMMON 1 "2020-03-07" "" "borg backup tool"
+.TH BORG-COMMON 1 "2020-06-06" "" "borg backup tool"
 .SH NAME
 borg-common \- Common options of Borg commands
 .
@@ -63,6 +63,9 @@ Output one JSON object per log line instead of formatted text.
 .BI \-\-lock\-wait \ SECONDS
 wait at most SECONDS for acquiring a repository/cache lock (default: 1).
 .TP
+.B \-\-bypass\-lock
+Bypass locking mechanism
+.TP
 .B \-\-show\-version
 show/log the borg version
 .TP

docs/man/borg-compression.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH BORG-COMPRESSION 1 "2020-03-07" "" "borg backup tool"
+.TH BORG-COMPRESSION 1 "2020-06-06" "" "borg backup tool"
 .SH NAME
 borg-compression \- Details regarding compression
 .

docs/man/borg-config.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH BORG-CONFIG 1 "2020-03-07" "" "borg backup tool"
+.TH BORG-CONFIG 1 "2020-06-06" "" "borg backup tool"
 .SH NAME
 borg-config \- get, set, and delete values in a repository or cache config file
 .

docs/man/borg-create.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH BORG-CREATE 1 "2020-03-07" "" "borg backup tool"
+.TH BORG-CREATE 1 "2020-06-06" "" "borg backup tool"
 .SH NAME
 borg-create \- Create new archive
 .

docs/man/borg-delete.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH BORG-DELETE 1 "2020-03-07" "" "borg backup tool"
+.TH BORG-DELETE 1 "2020-06-06" "" "borg backup tool"
 .SH NAME
 borg-delete \- Delete an existing repository or archives
 .

docs/man/borg-diff.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH BORG-DIFF 1 "2020-03-07" "" "borg backup tool"
+.TH BORG-DIFF 1 "2020-06-06" "" "borg backup tool"
 .SH NAME
 borg-diff \- Diff contents of two archives
 .

docs/man/borg-export-tar.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH BORG-EXPORT-TAR 1 "2020-03-07" "" "borg backup tool"
+.TH BORG-EXPORT-TAR 1 "2020-06-06" "" "borg backup tool"
 .SH NAME
 borg-export-tar \- Export archive contents as a tarball
 .

docs/man/borg-extract.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH BORG-EXTRACT 1 "2020-03-07" "" "borg backup tool"
+.TH BORG-EXTRACT 1 "2020-06-06" "" "borg backup tool"
 .SH NAME
 borg-extract \- Extract archive contents
 .

docs/man/borg-info.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH BORG-INFO 1 "2020-03-07" "" "borg backup tool"
+.TH BORG-INFO 1 "2020-06-06" "" "borg backup tool"
 .SH NAME
 borg-info \- Show archive details such as disk space used
 .

docs/man/borg-init.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH BORG-INIT 1 "2020-03-07" "" "borg backup tool"
+.TH BORG-INIT 1 "2020-06-06" "" "borg backup tool"
 .SH NAME
 borg-init \- Initialize an empty repository
 .
@@ -43,7 +43,11 @@ Encryption can be enabled at repository init time. It cannot be changed later.
 It is not recommended to work without encryption. Repository encryption protects
 you e.g. against the case that an attacker has access to your backup repository.
 .sp
-But be careful with the key / the passphrase:
+Borg relies on randomly generated key material and uses that for chunking, id
+generation, encryption and authentication. The key material is encrypted using
+the passphrase you give before it is stored on\-disk.
+.sp
+You need to be careful with the key / the passphrase:
 .sp
 If you want "passphrase\-only" security, use one of the repokey modes. The
 key will be stored inside the repository (in its "config" file). In above
@@ -81,6 +85,12 @@ a different keyboard layout.
 You can change your passphrase for existing repos at any time, it won\(aqt affect
 the encryption/decryption key or other secrets.
 .SS Encryption modes
+.sp
+You can choose from the encryption modes seen in the table below on a per\-repo
+basis. The mode determines encryption algorithm, hash/MAC algorithm and also the
+key storage location.
+.sp
+Example: \fIborg init \-\-encryption repokey ...\fP
 .\" nanorst: inline-fill
 .
 .TS
@@ -126,7 +136,8 @@ _
 .\" nanorst: inline-replace
 .
 .sp
-\fIMarked modes\fP are new in Borg 1.1 and are not backwards\-compatible with Borg 1.0.x.
+Modes \fImarked like this\fP in the above table are new in Borg 1.1 and are not
+backwards\-compatible with Borg 1.0.x.
 .sp
 On modern Intel/AMD CPUs (except very cheap ones), AES is usually
 hardware\-accelerated.
@@ -159,8 +170,8 @@ from the other blake2 modes.
 This mode is new and \fInot\fP compatible with Borg 1.0.x.
 .sp
 \fInone\fP mode uses no encryption and no authentication. It uses SHA256 as chunk
-ID hash. Not recommended, rather consider using an authenticated or
-authenticated/encrypted mode. This mode has possible denial\-of\-service issues
+ID hash. This mode is not recommended, you should rather consider using an authenticated
+or authenticated/encrypted mode. This mode has possible denial\-of\-service issues
 when running \fBborg create\fP on contents controlled by an attacker.
 Use it only for new repositories where no encryption is wanted \fBand\fP when compatibility
 with 1.0.x is important. If compatibility with 1.0.x is not important, use
@@ -203,9 +214,11 @@ $ borg init \-\-encryption=repokey\-blake2 /path/to/repo
 $ borg init \-\-encryption=none /path/to/repo
 
 # Remote repository (accesses a remote borg via ssh)
+# repokey: stores the (encrypted) key into <REPO_DIR>/config
 $ borg init \-\-encryption=repokey\-blake2 user@hostname:backup
 
-# Remote repository (store the key your home dir)
+# Remote repository (accesses a remote borg via ssh)
+# keyfile: stores the (encrypted) key into ~/.config/borg/keys/
 $ borg init \-\-encryption=keyfile user@hostname:backup
 .ft P
 .fi

docs/man/borg-key-change-passphrase.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH BORG-KEY-CHANGE-PASSPHRASE 1 "2020-03-07" "" "borg backup tool"
+.TH BORG-KEY-CHANGE-PASSPHRASE 1 "2020-06-06" "" "borg backup tool"
 .SH NAME
 borg-key-change-passphrase \- Change repository key file passphrase
 .

docs/man/borg-key-export.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH BORG-KEY-EXPORT 1 "2020-03-07" "" "borg backup tool"
+.TH BORG-KEY-EXPORT 1 "2020-06-06" "" "borg backup tool"
 .SH NAME
 borg-key-export \- Export the repository key for backup
 .

docs/man/borg-key-import.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH BORG-KEY-IMPORT 1 "2020-03-07" "" "borg backup tool"
+.TH BORG-KEY-IMPORT 1 "2020-06-06" "" "borg backup tool"
 .SH NAME
 borg-key-import \- Import the repository key from backup
 .

docs/man/borg-key-migrate-to-repokey.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH BORG-KEY-MIGRATE-TO-REPOKEY 1 "2020-03-07" "" "borg backup tool"
+.TH BORG-KEY-MIGRATE-TO-REPOKEY 1 "2020-06-06" "" "borg backup tool"
 .SH NAME
 borg-key-migrate-to-repokey \- Migrate passphrase -> repokey
 .

docs/man/borg-key.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH BORG-KEY 1 "2020-03-07" "" "borg backup tool"
+.TH BORG-KEY 1 "2020-06-06" "" "borg backup tool"
 .SH NAME
 borg-key \- Manage a keyfile or repokey of a repository
 .

docs/man/borg-list.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH BORG-LIST 1 "2020-03-07" "" "borg backup tool"
+.TH BORG-LIST 1 "2020-06-06" "" "borg backup tool"
 .SH NAME
 borg-list \- List archive or repository contents
 .

docs/man/borg-mount.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH BORG-MOUNT 1 "2020-03-07" "" "borg backup tool"
+.TH BORG-MOUNT 1 "2020-06-06" "" "borg backup tool"
 .SH NAME
 borg-mount \- Mount archive or an entire repository as a FUSE filesystem
 .

docs/man/borg-patterns.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH BORG-PATTERNS 1 "2020-03-07" "" "borg backup tool"
+.TH BORG-PATTERNS 1 "2020-06-06" "" "borg backup tool"
 .SH NAME
 borg-patterns \- Details regarding patterns
 .
@@ -37,17 +37,26 @@ currently active recursion root. You usually give the recursion root(s)
 when invoking borg and these can be either relative or absolute paths.
 .sp
 So, when you give \fIrelative/\fP as root, the paths going into the matcher
-will look like \fIrelative/.../file.ext\fP\&. When you give \fI/absolute/\fP as root,
-they will look like \fI/absolute/.../file.ext\fP\&. This is meant when we talk
-about "full path" below.
+will look like \fIrelative/.../file.ext\fP\&. When you give \fI/absolute/\fP as
+root, they will look like \fI/absolute/.../file.ext\fP\&. This is meant when
+we talk about "full path" below.
+.sp
+File paths in Borg archives are always stored normalized and relative.
+This means that e.g. \fBborg create /path/to/repo ../some/path\fP will
+store all files as \fIsome/path/.../file.ext\fP and \fBborg create
+/path/to/repo /home/user\fP will store all files as
+\fIhome/user/.../file.ext\fP\&. Therefore, always use relative paths in your
+patterns when matching archive content in commands like \fBextract\fP or
+\fBmount\fP\&. Starting with Borg 1.2 this behaviour will be changed to
+accept both absolute and relative paths.
 .sp
 File patterns support these styles: fnmatch, shell, regular expressions,
 path prefixes and path full\-matches. By default, fnmatch is used for
-\fB\-\-exclude\fP patterns and shell\-style is used for the experimental \fB\-\-pattern\fP
-option.
+\fB\-\-exclude\fP patterns and shell\-style is used for the experimental
+\fB\-\-pattern\fP option.
 .sp
-If followed by a colon (\(aq:\(aq) the first two characters of a pattern are used as a
-style selector. Explicit style selection is necessary when a
+If followed by a colon (\(aq:\(aq) the first two characters of a pattern are
+used as a style selector. Explicit style selection is necessary when a
 non\-default style is desired or when the desired pattern starts with
 two alphanumeric characters followed by a colon (i.e. \fIaa:something/*\fP).
 .INDENT 0.0

docs/man/borg-placeholders.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH BORG-PLACEHOLDERS 1 "2020-03-07" "" "borg backup tool"
+.TH BORG-PLACEHOLDERS 1 "2020-06-06" "" "borg backup tool"
 .SH NAME
 borg-placeholders \- Details regarding placeholders
 .

docs/man/borg-prune.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH BORG-PRUNE 1 "2020-03-07" "" "borg backup tool"
+.TH BORG-PRUNE 1 "2020-06-06" "" "borg backup tool"
 .SH NAME
 borg-prune \- Prune repository archives according to specified rules
 .

docs/man/borg-recreate.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH BORG-RECREATE 1 "2020-03-07" "" "borg backup tool"
+.TH BORG-RECREATE 1 "2020-06-06" "" "borg backup tool"
 .SH NAME
 borg-recreate \- Re-create archives
 .

docs/man/borg-rename.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH BORG-RENAME 1 "2020-03-07" "" "borg backup tool"
+.TH BORG-RENAME 1 "2020-06-06" "" "borg backup tool"
 .SH NAME
 borg-rename \- Rename an existing archive
 .

docs/man/borg-serve.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH BORG-SERVE 1 "2020-03-07" "" "borg backup tool"
+.TH BORG-SERVE 1 "2020-06-06" "" "borg backup tool"
 .SH NAME
 borg-serve \- Start in server mode. This command is usually not used manually.
 .

docs/man/borg-umount.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH BORG-UMOUNT 1 "2020-03-07" "" "borg backup tool"
+.TH BORG-UMOUNT 1 "2020-06-06" "" "borg backup tool"
 .SH NAME
 borg-umount \- un-mount the FUSE filesystem
 .

docs/man/borg-upgrade.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH BORG-UPGRADE 1 "2020-03-07" "" "borg backup tool"
+.TH BORG-UPGRADE 1 "2020-06-06" "" "borg backup tool"
 .SH NAME
 borg-upgrade \- upgrade a repository from a previous version
 .

docs/man/borg-with-lock.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH BORG-WITH-LOCK 1 "2020-03-07" "" "borg backup tool"
+.TH BORG-WITH-LOCK 1 "2020-06-06" "" "borg backup tool"
 .SH NAME
 borg-with-lock \- run a user specified command with the repository lock held
 .

docs/man/borg.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH BORG 1 "2017-02-05" "" "borg backup tool"
+.TH BORG 1 "2020-06-06" "" "borg backup tool"
 .SH NAME
 borg \- deduplicating and encrypting backup tool
 .
@@ -30,10 +30,26 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.SH SYNOPSIS
+.SH BORG
+.SS deduplicating and encrypting backup tool
+.INDENT 0.0
+.TP
+.B Author
+The Borg Collective
+.TP
+.B Date
+2020\-06\-06
+.TP
+.B Manual section
+1
+.TP
+.B Manual group
+borg backup tool
+.UNINDENT
+.SS SYNOPSIS
 .sp
 borg [common options] <command> [options] [arguments]
-.SH DESCRIPTION
+.SS DESCRIPTION
 .\" we don't include the README.rst here since we want to keep this terse.
 .
 .sp
@@ -50,7 +66,7 @@ Borg stores a set of files in an \fIarchive\fP\&. A \fIrepository\fP is a collec
 of \fIarchives\fP\&. The format of repositories is Borg\-specific. Borg does not
 distinguish archives from each other in any way other than their name,
 it does not matter when or where archives were created (e.g. different hosts).
-.SH EXAMPLES
+.SS EXAMPLES
 .SS A step\-by\-step example
 .INDENT 0.0
 .IP 1. 3
@@ -185,7 +201,7 @@ reports during command execution.  You can also add the \fB\-v\fP (or
 get other informational messages.
 .UNINDENT
 .UNINDENT
-.SH NOTES
+.SS NOTES
 .SS Positional Arguments and Options: Order matters
 .sp
 Borg only supports taking options (\fB\-s\fP and \fB\-\-progress\fP in the example)
@@ -465,9 +481,6 @@ in systemd.nspawn containers on some architectures (e.g. ARM).
 Using this does not affect data safety, but might result in a more bursty
 write to disk behaviour (not continuously streaming to disk).
 .UNINDENT
-.TP
-.B TMPDIR
-where temporary files are stored (might need a lot of temporary space for some operations), see \fI\%tempfile\fP for details
 .UNINDENT
 .TP
 .B Some automatic "answerers" (if set, they automatically answer confirmation questions):
@@ -497,27 +510,47 @@ allowed). So please test your scripts interactively before making them a non\-in
 .INDENT 7.0
 .TP
 .B BORG_BASE_DIR
-Default to \(aq$HOME\(aq, \(aq~$USER\(aq, \(aq~\(aq (in that order)\(aq.
-If we refer to ~ below, we in fact mean BORG_BASE_DIR.
+Defaults to \fB$HOME\fP or \fB~$USER\fP or \fB~\fP (in that order).
+If you want to move all borg\-specific folders to a custom path at once, all you need to do is
+to modify \fBBORG_BASE_DIR\fP: the other paths for cache, config etc. will adapt accordingly
+(assuming you didn\(aqt set them to a different custom value).
 .TP
 .B BORG_CACHE_DIR
-Default to \(aq~/.cache/borg\(aq. This directory contains the local cache and might need a lot
+Defaults to \fB$BORG_BASE_DIR/.cache/borg\fP\&. If \fBBORG_BASE_DIR\fP is not explicitly set while
+
+.nf
+\(gaXDG env var\(ga_
+.fi
+ \fBXDG_CACHE_HOME\fP is set, then \fB$XDG_CACHE_HOME/borg\fP is being used instead.
+This directory contains the local cache and might need a lot
 of space for dealing with big repositories. Make sure you\(aqre aware of the associated
 security aspects of the cache location: \fIcache_security\fP
 .TP
 .B BORG_CONFIG_DIR
-Default to \(aq~/.config/borg\(aq. This directory contains the whole config directories.
+Defaults to \fB$BORG_BASE_DIR/.config/borg\fP\&. If \fBBORG_BASE_DIR\fP is not explicitly set while
+
+.nf
+\(gaXDG env var\(ga_
+.fi
+ \fBXDG_CONFIG_HOME\fP is set, then \fB$XDG_CONFIG_HOME/borg\fP is being used instead.
+This directory contains all borg configuration directories, see the FAQ
+for a security advisory about the data in this directory: \fIhome_config_borg\fP
 .TP
 .B BORG_SECURITY_DIR
-Default to \(aq~/.config/borg/security\(aq. This directory contains information borg uses to
-track its usage of NONCES ("numbers used once" \- usually in encryption context) and other
-security relevant data. Will move with BORG_CONFIG_DIR variable unless specified.
+Defaults to \fB$BORG_CONFIG_DIR/security\fP\&.
+This directory contains information borg uses to track its usage of NONCES ("numbers used
+once" \- usually in encryption context) and other security relevant data.
 .TP
 .B BORG_KEYS_DIR
-Default to \(aq~/.config/borg/keys\(aq. This directory contains keys for encrypted repositories.
+Defaults to \fB$BORG_CONFIG_DIR/keys\fP\&.
+This directory contains keys for encrypted repositories.
 .TP
 .B BORG_KEY_FILE
 When set, use the given filename as repository key file.
+.TP
+.B TMPDIR
+This is where temporary files are stored (might need a lot of temporary space for some
+operations), see \fI\%tempfile\fP for details.
 .UNINDENT
 .TP
 .B Building:
@@ -543,10 +576,10 @@ will be linked against the system libzstd instead of a bundled implementation. (
 Please note:
 .INDENT 0.0
 .IP \(bu 2
-be very careful when using the "yes" sayers, the warnings with prompt exist for your / your data\(aqs security/safety
+Be very careful when using the "yes" sayers, the warnings with prompt exist for your / your data\(aqs security/safety.
 .IP \(bu 2
-also be very careful when putting your passphrase into a script, make sure it has appropriate file permissions
-(e.g. mode 600, root:root).
+Also be very careful when putting your passphrase into a script, make sure it has appropriate file permissions (e.g.
+mode 600, root:root).
 .UNINDENT
 .SS File systems
 .sp
@@ -681,7 +714,7 @@ $TMPDIR, $TEMP, or $TMP environment variable is properly set for the sshd
 process.
 For some OSes, this can be done just by setting the correct value in the
 .bashrc (or equivalent login config file for other shells), however in
-other cases it may be neccessary to first enable \fBPermitUserEnvironment yes\fP
+other cases it may be necessary to first enable \fBPermitUserEnvironment yes\fP
 in your \fBsshd_config\fP file, then add \fBenvironment="TMPDIR=/my/big/tmpdir"\fP
 at the start of the public key to be used in the \fBauthorized_hosts\fP file.
 .TP
@@ -847,7 +880,7 @@ This includes resource forks on Mac OS X.
 .IP [7] 5
 aka \fIBSD flags\fP\&. The Linux set of flags [1] is portable across platforms.
 The BSDs define additional flags.
-.SH SEE ALSO
+.SS SEE ALSO
 .sp
 \fIborg\-common(1)\fP for common command line options
 .sp

docs/man/borgfs.1

@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH BORGFS 1 "2020-03-07" "" "borg backup tool"
+.TH BORGFS 1 "2020-06-06" "" "borg backup tool"
 .SH NAME
 borgfs \- Mount archive or an entire repository as a FUSE filesystem
 .

docs/usage/check.rst.inc

@@ -86,44 +86,41 @@ The check command verifies the consistency of a repository and the corresponding
 
 First, the underlying repository data files are checked:
 
-- For all segments the segment magic (header) is checked
-- For all objects stored in the segments, all metadata (e.g. crc and size) and
+- For all segments, the segment magic header is checked.
+- For all objects stored in the segments, all metadata (e.g. CRC and size) and
   all data is read. The read data is checked by size and CRC. Bit rot and other
   types of accidental damage can be detected this way.
-- If we are in repair mode and a integrity error is detected for a segment,
-  we try to recover as many objects from the segment as possible.
-- In repair mode, it makes sure that the index is consistent with the data
-  stored in the segments.
-- If you use a remote repo server via ssh:, the repo check is executed on the
-  repo server without causing significant network traffic.
+- In repair mode, if an integrity error is detected in a segment, try to recover
+  as many objects from the segment as possible.
+- In repair mode, make sure that the index is consistent with the data stored in
+  the segments.
+- If checking a remote repo via ``ssh:``, the repo check is executed on the server
+  without causing significant network traffic.
 - The repository check can be skipped using the ``--archives-only`` option.
 
 Second, the consistency and correctness of the archive metadata is verified:
 
 - Is the repo manifest present? If not, it is rebuilt from archive metadata
   chunks (this requires reading and decrypting of all metadata and data).
-- Check if archive metadata chunk is present. if not, remove archive from
-  manifest.
+- Check if archive metadata chunk is present; if not, remove archive from manifest.
 - For all files (items) in the archive, for all chunks referenced by these
-  files, check if chunk is present.
-  If a chunk is not present and we are in repair mode, replace it with a same-size
-  replacement chunk of zeros.
-  If a previously lost chunk reappears (e.g. via a later backup) and we are in
-  repair mode, the all-zero replacement chunk will be replaced by the correct chunk.
-  This requires reading of archive and file metadata, but not data.
-- If we are in repair mode and we checked all the archives: delete orphaned
-  chunks from the repo.
-- if you use a remote repo server via ssh:, the archive check is executed on
-  the client machine (because if encryption is enabled, the checks will require
-  decryption and this is always done client-side, because key access will be
-  required).
-- The archive checks can be time consuming, they can be skipped using the
+  files, check if chunk is present. In repair mode, if a chunk is not present,
+  replace it with a same-size replacement chunk of zeroes. If a previously lost
+  chunk reappears (e.g. via a later backup), in repair mode the all-zero replacement
+  chunk will be replaced by the correct chunk. This requires reading of archive and
+  file metadata, but not data.
+- In repair mode, when all the archives were checked, orphaned chunks are deleted
+  from the repo. One cause of orphaned chunks are input file related errors (like
+  read errors) in the archive creation process.
+- If checking a remote repo via ``ssh:``, the archive check is executed on the
+  client machine because it requires decryption, and this is always done client-side
+  as key access is needed.
+- The archive checks can be time consuming; they can be skipped using the
   ``--repository-only`` option.
 
 The ``--verify-data`` option will perform a full integrity verification (as opposed to
 checking the CRC32 of the segment) of data, which means reading the data from the
 repository, decrypting and decompressing it. This is a cryptographic verification,
 which will detect (accidental) corruption. For encrypted repositories it is
-tamper-resistant as well, unless the attacker has access to the keys.
-
-It is also very slow.
+tamper-resistant as well, unless the attacker has access to the keys. It is also very
+slow.

docs/usage/common-options.rst.inc

@@ -8,6 +8,7 @@
 -p, --progress     show progress information
 --log-json         Output one JSON object per log line instead of formatted text.
 --lock-wait SECONDS    wait at most SECONDS for acquiring a repository/cache lock (default: 1).
+--bypass-lock      Bypass locking mechanism
 --show-version     show/log the borg version
 --show-rc          show/log the return code (rc)
 --umask M          set umask to M (local and remote, default: 0077)

docs/usage/help.rst.inc

@@ -11,17 +11,26 @@ currently active recursion root. You usually give the recursion root(s)
 when invoking borg and these can be either relative or absolute paths.
 
 So, when you give `relative/` as root, the paths going into the matcher
-will look like `relative/.../file.ext`. When you give `/absolute/` as root,
-they will look like `/absolute/.../file.ext`. This is meant when we talk
-about "full path" below.
+will look like `relative/.../file.ext`. When you give `/absolute/` as
+root, they will look like `/absolute/.../file.ext`. This is meant when
+we talk about "full path" below.
+
+File paths in Borg archives are always stored normalized and relative.
+This means that e.g. ``borg create /path/to/repo ../some/path`` will
+store all files as `some/path/.../file.ext` and ``borg create
+/path/to/repo /home/user`` will store all files as
+`home/user/.../file.ext`. Therefore, always use relative paths in your
+patterns when matching archive content in commands like ``extract`` or
+``mount``. Starting with Borg 1.2 this behaviour will be changed to
+accept both absolute and relative paths.
 
 File patterns support these styles: fnmatch, shell, regular expressions,
 path prefixes and path full-matches. By default, fnmatch is used for
-``--exclude`` patterns and shell-style is used for the experimental ``--pattern``
-option.
+``--exclude`` patterns and shell-style is used for the experimental
+``--pattern`` option.
 
-If followed by a colon (':') the first two characters of a pattern are used as a
-style selector. Explicit style selection is necessary when a
+If followed by a colon (':') the first two characters of a pattern are
+used as a style selector. Explicit style selection is necessary when a
 non-default style is desired or when the desired pattern starts with
 two alphanumeric characters followed by a colon (i.e. `aa:something/*`).
 

docs/usage/init.rst.inc

@@ -67,7 +67,11 @@ Encryption can be enabled at repository init time. It cannot be changed later.
 It is not recommended to work without encryption. Repository encryption protects
 you e.g. against the case that an attacker has access to your backup repository.
 
-But be careful with the key / the passphrase:
+Borg relies on randomly generated key material and uses that for chunking, id
+generation, encryption and authentication. The key material is encrypted using
+the passphrase you give before it is stored on-disk.
+
+You need to be careful with the key / the passphrase:
 
 If you want "passphrase-only" security, use one of the repokey modes. The
 key will be stored inside the repository (in its "config" file). In above
@@ -105,6 +109,12 @@ the encryption/decryption key or other secrets.
 Encryption modes
 ++++++++++++++++
 
+You can choose from the encryption modes seen in the table below on a per-repo
+basis. The mode determines encryption algorithm, hash/MAC algorithm and also the
+key storage location.
+
+Example: `borg init --encryption repokey ...`
+
 .. nanorst: inline-fill
 
 +----------+---------------+------------------------+--------------------------+
@@ -120,7 +130,8 @@ Encryption modes
 
 .. nanorst: inline-replace
 
-`Marked modes` are new in Borg 1.1 and are not backwards-compatible with Borg 1.0.x.
+Modes `marked like this` in the above table are new in Borg 1.1 and are not
+backwards-compatible with Borg 1.0.x.
 
 On modern Intel/AMD CPUs (except very cheap ones), AES is usually
 hardware-accelerated.
@@ -153,8 +164,8 @@ from the other blake2 modes.
 This mode is new and *not* compatible with Borg 1.0.x.
 
 `none` mode uses no encryption and no authentication. It uses SHA256 as chunk
-ID hash. Not recommended, rather consider using an authenticated or
-authenticated/encrypted mode. This mode has possible denial-of-service issues
+ID hash. This mode is not recommended, you should rather consider using an authenticated
+or authenticated/encrypted mode. This mode has possible denial-of-service issues
 when running ``borg create`` on contents controlled by an attacker.
 Use it only for new repositories where no encryption is wanted **and** when compatibility
 with 1.0.x is important. If compatibility with 1.0.x is not important, use

setup.py

@@ -7,7 +7,6 @@ from collections import OrderedDict
 from datetime import datetime
 from glob import glob
 
-from distutils.command.build import build
 from distutils.core import Command
 
 import textwrap
@@ -870,6 +869,7 @@ setup(
         'Programming Language :: Python :: 3.5',
         'Programming Language :: Python :: 3.6',
         'Programming Language :: Python :: 3.7',
+        'Programming Language :: Python :: 3.8',
         'Topic :: Security :: Cryptography',
         'Topic :: System :: Archiving :: Backup',
     ],