From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 28777 invoked from network); 4 Dec 2020 00:44:55 -0000 Received: from ewsd.inri.net (107.191.116.128) by inbox.vuxu.org with ESMTPUTF8; 4 Dec 2020 00:44:55 -0000 Received: from vultr.musolino.id.au ([45.76.123.158]) by ewsd; Thu Dec 3 19:40:06 -0500 2020 Received: from 58.170.131.8 ([58.170.131.8]) by vultr; Fri Dec 4 11:39:03 +1100 2020 Message-ID: From: Alex Musolino Date: Fri, 04 Dec 2020 11:09:02 +1030 To: 9front@9front.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: asynchronous distributed wrapper ActivityPub package firewall Subject: Re: [9front] Cannot Reply-To: 9front@9front.org Precedence: bulk Ah, you got me! I didn't actually try that part, figuring I'd be well done before 5am rolled around again. I just jotted it down when I came across it in my travels. So, you're right, startdump is a subcommand of cwcmd. However, looking at it now, fs(8) says: startdump [01] Suspend (0) or restart (1) the background dump process. But it seems like it actually behaves the other way around: cpu% con -C /srv/cwfs.cmd cwcmd startdump 1 dump stopped cwdcmd startdump 0 dump allowed  >>> q cpu% Any objections to the following patch to bring cwfs64x inline with the documentation? diff -r 91126ac896fa sys/src/cmd/cwfs/cw.c --- a/sys/src/cmd/cwfs/cw.c Sat Nov 28 23:03:44 2020 +1030 +++ b/sys/src/cmd/cwfs/cw.c Fri Dec 04 11:06:49 2020 +1030 @@ -2281,7 +2281,7 @@ blockcmp(dev, s1, s2); } else if(strcmp(arg, "startdump") == 0) { if(argc > 2) - cw->nodump = number(argv[2], 0, 10); + cw->nodump = !number(argv[2], 0, 10); else cw->nodump = !cw->nodump; if(cw->nodump)