|author||Dimitri John Ledkov <email@example.com>||2017-07-31 14:54:24 +0100|
|committer||Dimitri John Ledkov <firstname.lastname@example.org>||2017-07-31 14:54:24 +0100|
New upstream release.
Diffstat (limited to 'Documentation/btrfs-receive.asciidoc')
1 files changed, 23 insertions, 3 deletions
diff --git a/Documentation/btrfs-receive.asciidoc b/Documentation/btrfs-receive.asciidoc
index a6838e5e..1f6847a9 100644
@@ -23,7 +23,7 @@ previously generated by *btrfs send*. The received subvolumes are stored to
If '--dump' option is specified, *btrfs receive* will only do the validation of
the stream, and print the stream metadata, one operation per line.
-*btrfs receive* will fail int the following cases:
+*btrfs receive* will fail in the following cases:
1. receiving subvolume already exists
@@ -31,7 +31,7 @@ the stream, and print the stream metadata, one operation per line.
3. default subvolume has changed or you didn't mount the filesystem at the toplevel subvolume
-A subvolume is made read-only after the receiving process finishes succesfully.
+A subvolume is made read-only after the receiving process finishes successfully (see BUGS below).
@@ -66,7 +66,27 @@ tell us where this filesystem is mounted.
dump the stream metadata, one line per operation
-Does not require the 'path' parameter. The filesystem chanded.
+Does not require the 'path' parameter. The filesystem remains unchanged.
+*btrfs receive* sets the subvolume read-only after it completes
+successfully. However, while the receive is in progress, users who have
+write access to files or directories in the receiving 'path' can add,
+remove, or modify files, in which case the resulting read-only subvolume
+will not be an exact copy of the sent subvolume.
+If the intention is to create an exact copy, the receiving 'path'
+should be protected from access by users until the receive operation
+has completed and the subvolume is set to read-only.
+Additionally, receive does not currently do a very good job of validating
+that an incremental send streams actually makes sense, and it is thus
+possible for a specially crafted send stream to create a subvolume with
+reflinks to arbitrary files in the same filesystem. Because of this,
+users are advised to not use *btrfs receive* on send streams from
+untrusted sources, and to protect trusted streams when sending them
+across untrusted networks.