diff options
Diffstat (limited to 'Documentation/btrfs-receive.asciidoc')
| -rw-r--r-- | Documentation/btrfs-receive.asciidoc | 26 |
1 files changed, 23 insertions, 3 deletions
diff --git a/Documentation/btrfs-receive.asciidoc b/Documentation/btrfs-receive.asciidoc index a6838e5e..1f6847a9 100644 --- a/Documentation/btrfs-receive.asciidoc +++ b/Documentation/btrfs-receive.asciidoc @@ -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). `Options` @@ -66,7 +66,27 @@ tell us where this filesystem is mounted. --dump:: 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. + +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 ----------- |