* [PATCH] btrfs-progs: doc: correct the destination of btrfs-receive @ 2016-06-14 5:50 Satoru Takeuchi 2016-06-14 8:51 ` David Sterba 0 siblings, 1 reply; 5+ messages in thread From: Satoru Takeuchi @ 2016-06-14 5:50 UTC (permalink / raw) To: linux-btrfs@vger.kernel.org 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(-) 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. -- 2.5.5 ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] btrfs-progs: doc: correct the destination of btrfs-receive 2016-06-14 5:50 [PATCH] btrfs-progs: doc: correct the destination of btrfs-receive Satoru Takeuchi @ 2016-06-14 8:51 ` David Sterba 2016-06-14 9:16 ` Hugo Mills 0 siblings, 1 reply; 5+ messages in thread From: David Sterba @ 2016-06-14 8:51 UTC (permalink / raw) To: Satoru Takeuchi; +Cc: linux-btrfs@vger.kernel.org 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] btrfs-progs: doc: correct the destination of btrfs-receive 2016-06-14 8:51 ` David Sterba @ 2016-06-14 9:16 ` Hugo Mills 2016-06-15 1:55 ` Satoru Takeuchi 0 siblings, 1 reply; 5+ messages in thread From: Hugo Mills @ 2016-06-14 9:16 UTC (permalink / raw) To: dsterba, Satoru Takeuchi, linux-btrfs@vger.kernel.org [-- Attachment #1: Type: text/plain, Size: 1970 bytes --] 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. -- Hugo Mills | It's against my programming to impersonate a deity! hugo@... carfax.org.uk | http://carfax.org.uk/ | PGP: E2AB1DE4 | C3PO, Return of the Jedi [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] btrfs-progs: doc: correct the destination of btrfs-receive 2016-06-14 9:16 ` Hugo Mills @ 2016-06-15 1:55 ` Satoru Takeuchi 2016-06-15 8:09 ` David Sterba 0 siblings, 1 reply; 5+ messages in thread From: Satoru Takeuchi @ 2016-06-15 1:55 UTC (permalink / raw) To: Hugo Mills, dsterba, linux-btrfs@vger.kernel.org On 2016/06/14 18:16, Hugo Mills wrote: > 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. The problem is on my side. I'm sorry. >> >>> @@ -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. You're right. These are added to charset="iso-2022-jp" plain text mail since thunderbird 45. I disabled the setting that appends the above mentioned options. So, probably the following sample patch doesn't have strange spaces. =================================== We can set not only btrfs mount points but also any paths 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(-) 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. -- 2.5.5 =================================== Thanks, Satoru > > Hugo. > ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] btrfs-progs: doc: correct the destination of btrfs-receive 2016-06-15 1:55 ` Satoru Takeuchi @ 2016-06-15 8:09 ` David Sterba 0 siblings, 0 replies; 5+ messages in thread From: David Sterba @ 2016-06-15 8:09 UTC (permalink / raw) To: Satoru Takeuchi; +Cc: Hugo Mills, linux-btrfs@vger.kernel.org On Wed, Jun 15, 2016 at 10:55:45AM +0900, Satoru Takeuchi wrote: > >> 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. > > You're right. These are added to charset="iso-2022-jp" plain text > mail since thunderbird 45. > > I disabled the setting that appends the above mentioned options. > So, probably the following sample patch doesn't have strange spaces. Yes, looks good now, thanks. ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-06-15 8:09 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-06-14 5:50 [PATCH] btrfs-progs: doc: correct the destination of btrfs-receive Satoru Takeuchi 2016-06-14 8:51 ` David Sterba 2016-06-14 9:16 ` Hugo Mills 2016-06-15 1:55 ` Satoru Takeuchi 2016-06-15 8:09 ` David Sterba
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).