[PATCH] btrfs-progs: doc: correct the destination of btrfs-receive

[PATCH] btrfs-progs: doc: correct the destination of btrfs-receive

[Satoru Takeuchi]

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

Re: [PATCH] btrfs-progs: doc: correct the destination of btrfs-receive

[David Sterba]

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.

Re: [PATCH] btrfs-progs: doc: correct the destination of btrfs-receive

[Hugo Mills]

[-- 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 --]

Re: [PATCH] btrfs-progs: doc: correct the destination of btrfs-receive

[Satoru Takeuchi]

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.
> 

Re: [PATCH] btrfs-progs: doc: correct the destination of btrfs-receive

[David Sterba]

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.