On 03/02/17 12:44, Austin S. Hemmelgarn wrote: > I can look at making a patch for this, but it may be next week before I > have time (I'm not great at multi-tasking when it comes to software > development, and I'm in the middle of helping to fix a bug in Ansible > right now).
That would be great, Austin! It is about 15 years since I last submitted a patch under kernel development patch rules and things have changed a fair bit in that time. So if you are set up to do it that sounds good. As a starting point, I have created a suggested text (patch attached).
diff --git a/Documentation/btrfs-receive.asciidoc b/Documentation/btrfs-receive.asciidoc index 6be4aa6..db525d9 100644 --- a/Documentation/btrfs-receive.asciidoc +++ b/Documentation/btrfs-receive.asciidoc @@ -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 succesfully (see BUGS below). `Options` @@ -73,6 +73,16 @@ EXIT STATUS *btrfs receive* returns a zero exit status if it succeeds. Non zero is returned in case of failure. +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 a copy of the sending subvolume. + +If the intention is to create an exact copy, the receiving 'path' should be protected +from access by users until the receive has completed and the subvolume set to read-only. + AVAILABILITY ------------ *btrfs* is part of btrfs-progs.
