From owner-svn-src-head@freebsd.org Sat Sep 19 23:27:23 2020 Return-Path: Delivered-To: svn-src-head@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4B72D3F239C; Sat, 19 Sep 2020 23:27:23 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Bv6LM112zz4dKb; Sat, 19 Sep 2020 23:27:23 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qk1-f170.google.com (mail-qk1-f170.google.com [209.85.222.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 009831F664; Sat, 19 Sep 2020 23:27:22 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qk1-f170.google.com with SMTP id 16so10989226qkf.4; Sat, 19 Sep 2020 16:27:22 -0700 (PDT) X-Gm-Message-State: AOAM531P5RhUlDAQK/kwNKCZzy1tg2uTQBpSI3q791P60PaeAjKVWJZQ lWEIUXyk6Mpeyiz2iC+OfQJMVL/mc+Y7aIrQqZk= X-Google-Smtp-Source: ABdhPJw3r4I/s8GNuzglb+szrG+5yKnjDETEGhT/Zmh3/fgOLAqbc5c4owk8NW9lcsOkQaUUqBYIfkJ5LKFSY98+su8= X-Received: by 2002:a05:620a:136e:: with SMTP id d14mr19348764qkl.430.1600558042387; Sat, 19 Sep 2020 16:27:22 -0700 (PDT) MIME-Version: 1.0 References: <202009112049.08BKnavL032212@repo.freebsd.org> <20200911214327.GY94807@kib.kiev.ua> In-Reply-To: From: Kyle Evans Date: Sat, 19 Sep 2020 18:27:11 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: svn commit: r365643 - head/bin/cp To: Rick Macklem Cc: Alan Somers , Konstantin Belousov , "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2020 23:27:23 -0000 On Sat, Sep 19, 2020 at 6:19 PM Rick Macklem wrote: > > Alan Somers wrote: > >On Fri, Sep 11, 2020 at 3:52 PM Rick Macklem > wrote: > >Konstantin Belousov wrote: > >>On Fri, Sep 11, 2020 at 08:49:36PM +0000, Alan Somers wrote: > >>> Author: asomers > >>> Date: Fri Sep 11 20:49:36 2020 > >>> New Revision: 365643 > >>> URL: https://svnweb.freebsd.org/changeset/base/365643 > >>> > >>> Log: > >>> cp: fall back to read/write if copy_file_range fails > >>> > >>> Even though copy_file_range has a file-system agnostic version, it still > >>> fails on devfs (perhaps because the file descriptor is non-seekable?) In > >>> that case, fallback to old-fashioned read/write. Fixes > >>> "cp /dev/null /tmp/null" > >> > >>Devices are seekable. > >> > >>The reason for EINVAL is that vn_copy_file_range() checks that both in and out > >>vnodes are VREG. For devfs, they are VCHR. > > > >I coded the syscall to the Linux man page, which states that EINVAL is returned > >if either fd does not refer to a regular file. > >Having said that, I do not recall testing the VCHR case under Linux. (ie. It might > >actually work and the man page turns out to be incorrect?) > > > >I will test this case under Linux when I get home next week, rick > I'll admit I haven't tested this in Linux to see if they do return EINVAL. > > >Since there's no standard, I think it's fine for us to support devfs if possible. > 1 - I think this is a good question for a mailing list like freebsd-current@. > 2 - I see Linux as the de-facto standard these days and consider POSIX no > longer relevant, but that's just mho. > 3 - For NFSv4.2, the Copy operation will fail for non-regular files, so if you > do this, you will need to handle the fall-back to using the generic code. > (Should be doable, but you need to be aware of this case.) > > Having said the above, it is up to the "collective" and not me and, as such, > I suggest #1, to see whether others think doing a non-Linux compatible > version makes sense for FreeBSD? > Testing on Debian I seem to get back an EINVAL, but I think it's maybe a little surprising: EXDEV The files referred to by file_in and file_out are not on the same mounted filesystem. Thanks, Kyle Evans