From nobody Fri Apr 05 13:41:31 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4VB05N23yMz5GTnP for ; Fri, 5 Apr 2024 13:41:44 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ua1-f48.google.com (mail-ua1-f48.google.com [209.85.222.48]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VB05M6qq4z42xT for ; Fri, 5 Apr 2024 13:41:43 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ua1-f48.google.com with SMTP id a1e0cc1a2514c-7e3555015a8so759260241.3 for ; Fri, 05 Apr 2024 06:41:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712324503; x=1712929303; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=5zwR0lJ1LPV998qvSsM1rOystsOoaVLHxJbH1O2ELY0=; b=OW19+ZeE8PF4qq4Epn2cb8CErrYn3fykdHDqCzf/v/D+4SB/zfGZfPSqP38tX1DVrk 45Gd1pM186PVzEcSvVqHSLJYVkEYc2SYWybfZTaL6zIWW29HZC/iJcEjsAj0UHCeK79u oAX53Q5+8DRz/AORj3CAmn+0oqP0V1wDF8W2AaEWu2ND4ExfzvmZD2YY0wR6GMt9o5mF 5BilO8T2OaNloUVoqCc9zRAXiX1FnNEOmjrne5CZKjKeKTUuzdkhnhpJBH0mxRnZbuYL /wlh9UlRd1UdOAqDsCm3kjKzlQga/ngNp2OqqRL3tvsGTXJQL11RL4vL8SMu51kWImlv 5mNg== X-Gm-Message-State: AOJu0Yw0eXXyGuz/dPDif6ttp7XGsSMHzjUzba8ptSPSgSs9e7TlI+gi erOXQkpfQaH8lqkjhHt5htQt4hPJhSj8hD6WYLGxD5xZ82uU1v6U9bgrCp7ihLTib0gGz5LvFpB +yXxjxSs8IvKIfbHPpGaMxH2Ybh7XpjAh X-Google-Smtp-Source: AGHT+IHyLJSw3smpIG0uyT89yOs5BjVZp7G96sbNAzexY62tToSXU3Ss+GgNgKY9JbMKALhg3+7rkr4tf7tWqvPKRSI= X-Received: by 2002:a05:6122:1792:b0:4d3:3846:73bb with SMTP id o18-20020a056122179200b004d3384673bbmr1833706vkf.7.1712324502904; Fri, 05 Apr 2024 06:41:42 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <202404050543.4355hDcS009860@critter.freebsd.dk> In-Reply-To: <202404050543.4355hDcS009860@critter.freebsd.dk> From: Alan Somers Date: Fri, 5 Apr 2024 07:41:31 -0600 Message-ID: Subject: Re: SEEK_HOLE at EOF To: Poul-Henning Kamp Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4VB05M6qq4z42xT On Thu, Apr 4, 2024 at 11:43=E2=80=AFPM Poul-Henning Kamp wrote: > > -------- > Alan Somers writes: > > > Linux's man page is clear: "whence is SEEK_DATA or SEEK_HOLE, and > > offset is beyond the end of the file". > >[...] > > Contrary to its man page, Linux behaves mostly like FreeBSD. SEEK_HOLE > > returns ENXIO at EOF on most file systems. > > Just two minor quibbles: > > If the file position is EOF, then you /are/ "beyond the end of the file" > because a read(2) would not be able to return any data. Do you distinguish between "at EOF" and "beyond EOF"? And does it not trouble you that calling SEEK_HOLE from the beginning of the "virtual hole at EOF" will return ENXIO, even though calling SEEK_HOLE from the beginning of any real hole will return the current offset? > > And returning ENXIO is more informative than returning the size of the > file, since it atomically tells you that there are no more holes. Ahh, that's a good point. It's the first point I've heard in favor of this option. Are you aware of any applications that need to know that? > > If it returned the size of the file, you would have to make another > syscall (opening a race) to check if what you got was EOF or a hole. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetenc= e.