From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5EC28ECE58E for ; Thu, 17 Oct 2019 16:14:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3B04320872 for ; Thu, 17 Oct 2019 16:14:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2406500AbfJQQOr (ORCPT ); Thu, 17 Oct 2019 12:14:47 -0400 Received: from fieldses.org ([173.255.197.46]:37462 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2404628AbfJQQOr (ORCPT ); Thu, 17 Oct 2019 12:14:47 -0400 Received: by fieldses.org (Postfix, from userid 2815) id C9D8F1B96; Thu, 17 Oct 2019 12:14:46 -0400 (EDT) Date: Thu, 17 Oct 2019 12:14:46 -0400 From: "J. Bruce Fields" To: Rick Macklem Cc: "Kornievskaia, Olga" , "linux-nfs@vger.kernel.org" , "nfsv4@ietf.org" Subject: Re: NFSv4.2 server replies to Copy with length == 0 Message-ID: <20191017161446.GI32141@fieldses.org> References: <20191016155838.GA17543@fieldses.org> <31E6043B-090D-4E37-B66F-A45AC0CFC970@netapp.com> <20191016203150.GC17543@fieldses.org> <20191017152253.GG32141@fieldses.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Thu, Oct 17, 2019 at 03:55:28PM +0000, Rick Macklem wrote: > ps: When I re-read it, the comment I made related to Bruce's "wrong" > was blunt (or maybe rude). It's OK! I'm possibly being annoying about this kinda trivial thing anyway. > I apologize for the tone. All I had intended to say was "although it > might not be our preferred semantic, it appears to clear and > implementable, so I do not think it can be "clarified" to be the way > the Linux server does it". I actually prefer the way the Linux server > does it, but it is too late now, imho. For the COPY case at least, implementations seem to be rare and new. Is it really that trivial to fix up the mismatch? Actually, I guess so: if I'm implementing the copy using read and write, then a 0-length read result from a nonzero read call can only mean end of file, so there's no need to do a second check of the file length or anything. Hm. --b.