| Message ID | 491d91eb-0d51-b8ba-a046-61e2e392f06e@jp.fujitsu.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
On Tue, Jun 14, 2016 at 02:50:19PM +0900, Satoru Takeuchi wrote: > We can set not only btrfs mount point but also any path belong to > btrfs mount point as btrfs-receive's destination. > > Signed-off-by: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com> The patches from you have a consistent whitespace damage, I've fixed the btrfs-crc but now that I see it again I suspect some error on your side. > @@ -7,14 +7,14 @@ btrfs-receive - receive subvolumes from send stream > > SYNOPSIS > -------- > -*btrfs receive* [options] <mount> > +*btrfs receive* [options] <path> > > 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 > -'mount'. > +'path'. > > *btrfs receive* will fail int the following cases: > > @@ -37,7 +37,7 @@ by default, btrfs receive uses standard input to receive the stream, > use this option to read from a file instead > > -C|--chroot:: > -confine the process to 'mount' using `chroot`(1) > +confine the process to 'path' using `chroot`(1) > > -e:: > terminate after receiving an 'end cmd' marker in the stream. ie. all the context lines start with two spaces instead of one. I'll apply this patch manually but please have a look. -- 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 Tue, Jun 14, 2016 at 10:51:33AM +0200, David Sterba wrote: > On Tue, Jun 14, 2016 at 02:50:19PM +0900, Satoru Takeuchi wrote: > > We can set not only btrfs mount point but also any path belong to > > btrfs mount point as btrfs-receive's destination. > > > > Signed-off-by: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com> > > The patches from you have a consistent whitespace damage, I've fixed > the btrfs-crc but now that I see it again I suspect some error on your > side. > > > @@ -7,14 +7,14 @@ btrfs-receive - receive subvolumes from send stream > > > > SYNOPSIS > > -------- > > -*btrfs receive* [options] <mount> > > +*btrfs receive* [options] <path> > > > > 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 > > -'mount'. > > +'path'. > > > > *btrfs receive* will fail int the following cases: > > > > @@ -37,7 +37,7 @@ by default, btrfs receive uses standard input to receive the stream, > > use this option to read from a file instead > > > > -C|--chroot:: > > -confine the process to 'mount' using `chroot`(1) > > +confine the process to 'path' using `chroot`(1) > > > > -e:: > > terminate after receiving an 'end cmd' marker in the stream. > > ie. all the context lines start with two spaces instead of one. I'll > apply this patch manually but please have a look. Looking at this, I suspect it's a consequence of sending it as "Content-Type: format=flowed; delsp=yes". I'm not sure which of those two options is the culprit. When I look at the message in my client (mutt), it looks absolutely fine. When I pipe it to hexdump, the double-spacing is apparent. Hugo.
diff --git a/Documentation/btrfs-receive.asciidoc b/Documentation/btrfs-receive.asciidoc index fbbded2..e246603 100644 --- a/Documentation/btrfs-receive.asciidoc +++ b/Documentation/btrfs-receive.asciidoc @@ -7,14 +7,14 @@ btrfs-receive - receive subvolumes from send stream SYNOPSIS -------- -*btrfs receive* [options] <mount> +*btrfs receive* [options] <path> 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 -'mount'. +'path'. *btrfs receive* will fail int the following cases: @@ -37,7 +37,7 @@ by default, btrfs receive uses standard input to receive the stream, use this option to read from a file instead -C|--chroot:: -confine the process to 'mount' using `chroot`(1) +confine the process to 'path' using `chroot`(1) -e:: terminate after receiving an 'end cmd' marker in the stream.
We can set not only btrfs mount point but also any path belong to btrfs mount point as btrfs-receive's destination. Signed-off-by: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com> --- Documentation/btrfs-receive.asciidoc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)