summaryrefslogtreecommitdiff
path: root/Documentation/btrfs-receive.asciidoc
diff options
context:
space:
mode:
authorNicholas D Steeves <nsteeves@gmail.com>2017-12-07 21:26:09 +0100
committerDavid Sterba <dsterba@suse.com>2018-01-03 17:29:19 +0100
commit8c5db79d0f3bd392b2d0965a4444de7726012bee (patch)
treedffae6003c8bb9a6fa851ebf876ef73827eef1ee /Documentation/btrfs-receive.asciidoc
parent1f360220714ba3516c262287d1f6453a10308834 (diff)
btrfs-progs: docs: annual typo, clarity, & grammar review & fixups
Signed-off-by: Nicholas D Steeves <nsteeves@gmail.com> Signed-off-by: David Sterba <dsterba@suse.com>
Diffstat (limited to 'Documentation/btrfs-receive.asciidoc')
-rw-r--r--Documentation/btrfs-receive.asciidoc2
1 files changed, 1 insertions, 1 deletions
diff --git a/Documentation/btrfs-receive.asciidoc b/Documentation/btrfs-receive.asciidoc
index 1f6847a9..cbd88e6a 100644
--- a/Documentation/btrfs-receive.asciidoc
+++ b/Documentation/btrfs-receive.asciidoc
@@ -81,7 +81,7 @@ 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
+that an incremental send stream 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