Re: [PATCH] btrfs-progs: doc: correct the destination of btrfs-receive
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. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] btrfs-progs: doc: correct the destination of btrfs-receive
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 >> >> 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] >>> +*btrfs receive* [options] >>> >>> 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 --- 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] +*btrfs receive* [options] 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. > -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] btrfs-progs: doc: correct the destination of btrfs-receive
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 > > 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] > > +*btrfs receive* [options] > > > > 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 signature.asc Description: Digital signature
Re: [PATCH] btrfs-progs: doc: correct the destination of btrfs-receive
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 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] > +*btrfs receive* [options] > > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] btrfs-progs: doc: correct the destination of btrfs-receive
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 --- 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] +*btrfs receive* [options] 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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
