From patchwork Wed Jun 15 01:55:45 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Satoru Takeuchi X-Patchwork-Id: 9177219 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 01DBD604DB for ; Wed, 15 Jun 2016 01:56:55 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id C8AE228303 for ; Wed, 15 Jun 2016 01:56:55 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id BB4CB28342; Wed, 15 Jun 2016 01:56:55 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 3054828303 for ; Wed, 15 Jun 2016 01:56:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932254AbcFOB4k (ORCPT ); Tue, 14 Jun 2016 21:56:40 -0400 Received: from mgwym03.jp.fujitsu.com ([211.128.242.42]:11670 "EHLO mgwym03.jp.fujitsu.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932241AbcFOB4j (ORCPT ); Tue, 14 Jun 2016 21:56:39 -0400 Received: from yt-mxoi1.gw.nic.fujitsu.com (unknown [192.168.229.67]) by mgwym03.jp.fujitsu.com with smtp id 573b_f137_a453ad33_0526_438a_b5a8_1e3ae84b5edc; Wed, 15 Jun 2016 10:56:35 +0900 Received: from m3050.s.css.fujitsu.com (msm.b.css.fujitsu.com [10.134.21.208]) by yt-mxoi1.gw.nic.fujitsu.com (Postfix) with ESMTP id DF688AC00FE for ; Wed, 15 Jun 2016 10:56:34 +0900 (JST) X-SecurityPolicyCheck: OK by SHieldMailChecker v2.4.6 X-SHieldMailCheckerPolicyVersion: FJ-ISEC-20160122 X-SHieldMailCheckerMailID: 5cc922a46fc64b7e9740cc3a18f7a353 Subject: Re: [PATCH] btrfs-progs: doc: correct the destination of btrfs-receive To: Hugo Mills , dsterba@suse.cz, "linux-btrfs@vger.kernel.org" References: <491d91eb-0d51-b8ba-a046-61e2e392f06e@jp.fujitsu.com> <20160614085133.GE6205@twin.jikos.cz> <20160614091608.GC5437@carfax.org.uk> From: Satoru Takeuchi Message-ID: <9a4c1521-f1eb-8eaf-59c8-f2e0cb897ed9@jp.fujitsu.com> Date: Wed, 15 Jun 2016 10:55:45 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160614091608.GC5437@carfax.org.uk> X-TM-AS-MML: disable Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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.