| Message ID | a85af6d8-fdcd-1039-3c0e-a4486ff0bb0a@cobb.uk.net (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 2017-02-03 10:44, Graham Cobb wrote: > 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). Ironically, I ended up having time sooner than I thought. The message doesn't appear to be in any of the archives yet, but the message ID is: <20170203134858.75210-1-ahferroin7@gmail.com> I actually like how you explained things a bit better though, so if you are OK with it I'll update the patch I sent using your description (and credit you in the commit message too of course). -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 03/02/17 16:01, Austin S. Hemmelgarn wrote: > Ironically, I ended up having time sooner than I thought. The message > doesn't appear to be in any of the archives yet, but the message ID is: > <20170203134858.75210-1-ahferroin7@gmail.com> Ah. I didn't notice it until after I had sent my message. > I actually like how you explained things a bit better though, so if you > are OK with it I'll update the patch I sent using your description (and > credit you in the commit message too of course). You are welcome to use any of my phrasing or approach, of course! -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2017-02-03 14:17, Graham Cobb wrote: > On 03/02/17 16:01, Austin S. Hemmelgarn wrote: >> Ironically, I ended up having time sooner than I thought. The message >> doesn't appear to be in any of the archives yet, but the message ID is: >> <20170203134858.75210-1-ahferroin7@gmail.com> > > Ah. I didn't notice it until after I had sent my message. No worries. > >> I actually like how you explained things a bit better though, so if you >> are OK with it I'll update the patch I sent using your description (and >> credit you in the commit message too of course). > > You are welcome to use any of my phrasing or approach, of course! > I'll send out the new version shortly then. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.