btrfs-progs: docs: fix many typos, plus three edits for clarity
[platform/upstream/btrfs-progs.git] / Documentation / btrfs-receive.asciidoc
index e246603..1f6847a 100644 (file)
@@ -9,32 +9,37 @@ SYNOPSIS
 --------
 *btrfs receive* [options] <path>
 
+or
+
+*btrfs receive* --dump [options]
+
 DESCRIPTION
 -----------
 
 Receive a stream of changes and replicate one or more subvolumes that were
-previously used with *btrfs send* The received subvolumes are stored to
-'path'.
+previously generated by *btrfs send*. The received subvolumes are stored to
+'path', unless '--dump' option is given.
 
-*btrfs receive* will fail int the following cases:
+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 in the following cases:
 
 1. receiving subvolume already exists
 
-2. previously received subvolume was changed after it was received
+2. previously received subvolume has been changed after it was received
 
-3. default subvolume has changed or you didn't mount BTRFS filesystem at the toplevel subvolume
+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).
 
 `Options`
 
 -v::
-enable verbose debug output, print each operation (each occurrence of this
-option increases the verbosity level)
+increase verbosity about performed actions, print details about each operation
 
--f <infile>::
-by default, btrfs receive uses standard input to receive the stream,
-use this option to read from a file instead
+-f <FILE>::
+read the stream from <FILE> instead of stdin,
 
 -C|--chroot::
 confine the process to 'path' using `chroot`(1)
@@ -42,19 +47,46 @@ confine the process to 'path' using `chroot`(1)
 -e::
 terminate after receiving an 'end cmd' marker in the stream.
 +
-Without this option, the receiver terminates only if an error is encountered
-or at end of file
+Without this option the receiver side terminates only in case
+of an error on end of file.
 
---max-errors <N>::
-terminate as soon as N errors happened while processing commands from the send
-stream, default value is 1, 0 means no limit
+-E|--max-errors <NERR>::
+terminate as soon as NERR errors occur while stream processing commands from
+the stream
++
+Default value is 1. A value of 0 means no limit.
 
--m <mountpoint>::
+-m <ROOTMOUNT>::
 the root mount point of the destination filesystem
 +
 By default the mountpoint is searched in '/proc/self/mounts'.
-If you do not have '/proc', eg. in a chroot environment, use this option to tell
-us where this filesystem is mounted.
+If '/proc' is not accessible, eg. in a chroot environment, use this option to
+tell us where this filesystem is mounted.
+
+--dump::
+dump the stream metadata, one line per operation
++
+Does not require the 'path' parameter. The filesystem remains unchanged.
+
+BUGS
+----
+*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.
 
 EXIT STATUS
 -----------