Debian Bug report logs - #1036651
coreutils: split: -n <digit> with (some?) devices fails with EOVERFLOW, accepts some chardevs?

version graph

Package: coreutils; Maintainer for coreutils is Michael Stone <[email protected]>; Source for coreutils is src:coreutils (PTS, buildd, popcon).

Reported by: наб <[email protected]>

Date: Tue, 23 May 2023 19:45:12 UTC

Severity: normal

Found in version coreutils/8.32-4

Full log

Message #10 received at [email protected] (full text, mbox, reply):

Received: (at 1036651) by bugs.debian.org; 23 May 2023 21:16:48 +0000
From [email protected] Tue May 23 21:16:48 2023
X-Spam-Checker-Version: SpamAssassin 3.4.6-bugs.debian.org_2005_01_02
	(2021-04-09) on buxtehude.debian.org
X-Spam-Level: 
X-Spam-Status: No, score=-4.6 required=4.0 tests=BAYES_00,DIGITS_LETTERS,
	DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,FREEMAIL_FORGED_FROMDOMAIN,
	FREEMAIL_FROM,HAS_BUG_NUMBER,HEADER_FROM_DIFFERENT_DOMAINS,
	RCVD_IN_DNSWL_NONE,SHIP_ID_INT,SPF_HELO_NONE,SPF_PASS,
	T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no
	version=3.4.6-bugs.debian.org_2005_01_02
X-Spam-Bayes: score:0.0000 Tokens: new, 15; hammy, 150; neutral, 48; spammy,
	0. spammytokens: hammytokens:0.000-+--rfkill, 0.000-+--Maintainer,
	0.000-+--strerror, 0.000-+--H*r:TLS1_3,
	0.000-+--Hx-spam-relays-external:sk:smtp.go
Return-path: <[email protected]>
Received: from mail-wm1-x333.google.com ([2a00:1450:4864:20::333]:50476)
	by buxtehude.debian.org with esmtps (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_128_GCM:128)
	(Exim 4.94.2)
	(envelope-from <[email protected]>)
	id 1q1ZNA-00Cm0I-Q7
	for [email protected]; Tue, 23 May 2023 21:16:48 +0000
Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-3f60410106cso2410765e9.1
        for <[email protected]>; Tue, 23 May 2023 14:16:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20221208; t=1684876604; x=1687468604;
        h=content-transfer-encoding:in-reply-to:from:references:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :sender:from:to:cc:subject:date:message-id:reply-to;
        bh=K2O9eb6rSerFOT/QOzjiOQYfHlKMLz9+JPoy8Jmk/CQ=;
        b=BJBXdtGtOzRiB5aAGJR0Md/OMU+PvoGlzTaYLUgT/7AOX57FIq5Xy6Tw33s25Gh/fG
         8/QoO6VTJJT1xAfTAF0MXF57G5bkQffTTvq4IaIMsRHrHZ/VlG637K6k3Hr9TwDiYJow
         yqU8k5s0tvC7glLbAEDasQC/gBJyl3H9VHBdbzQcjjNgYEIPXbvyypQSQ1oILG5TtJD2
         4aRgfVp+F6eaIhrw2PTFbsc/kigwNKRbahUBJOaMK9sNqhEgsCb1YBa2JnAj0OVHhs6h
         OLLpiWklBL1ekEtrKaPom2tpB8vMdyjdhYdR5Ua43RIrB0BvFrdlEg5rhVZBSSQQ65Hx
         UgPw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20221208; t=1684876604; x=1687468604;
        h=content-transfer-encoding:in-reply-to:from:references:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :sender:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=K2O9eb6rSerFOT/QOzjiOQYfHlKMLz9+JPoy8Jmk/CQ=;
        b=LuJZl+sNubEWo2Kb65pYIKOtKgYRt4hYyVGZsUbuCGNOR2xBGVl58q5Xg6lJcT1Eqs
         aPaXyiOg/lFPlnBXGkgy1dzEJgs/yYWFjVpY3IL8V4pmphK2xaJXkl/VdZaN/TSydkdc
         NIYZiAE9xkJQze2FrOcR1SmxLLC/tw8f5K0UigWNLbG7LDBSFRa92u0YYJ6oB2VvKWGG
         lx1Qf8+/mJJliduHcisCrrPPHC3Frutk+MzorBNocFc7nVEx045y1yU4UB47U8FWjaKa
         mpCrFZztw+vIPLfSQ5AjB0fzDonO8JE80zpLPqbIbCncBdbYAzbfYV5U95fyoxckuoT5
         8eFA==
X-Gm-Message-State: AC+VfDzWu3f0FMDUhX2Tls1tYO75YT1GxuY51DznbENPBpbD2xPu9QW1
	MZnNvzH84I/vh/pZsCGEZY+QioctP80=
X-Google-Smtp-Source: ACHHUZ7DzbviGmTLXObs4H2X+8ScYT/aWNbuRv6dF1uRLtVemv9PpQiloSUqAmSElaEGpIh/gdj/ig==
X-Received: by 2002:a05:600c:2309:b0:3f4:239c:f19 with SMTP id 9-20020a05600c230900b003f4239c0f19mr9971395wmo.36.1684876604172;
        Tue, 23 May 2023 14:16:44 -0700 (PDT)
Received: from [192.168.1.19] (95-44-90-175-dynamic.agg2.lod.rsl-rtd.eircom.net. [95.44.90.175])
        by smtp.googlemail.com with ESMTPSA id i14-20020adffdce000000b003095bd71159sm12378906wrs.7.2023.05.23.14.16.43
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Tue, 23 May 2023 14:16:43 -0700 (PDT)
Sender: Pádraig Brady <[email protected]>
Message-ID: <[email protected]>
Date: Tue, 23 May 2023 22:16:42 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Bug#1036651: coreutils: split: -n <digit> with (some?) devices
 fails with EOVERFLOW, accepts some chardevs?
Content-Language: en-US
To: наб <[email protected]>,
 [email protected]
References: <imejfku6lvfhopegazaqvkrxciqsyevmlchugrcbsfixn6l6cn@bhgwmw4of3tw>
From: Pádraig Brady <[email protected]>
In-Reply-To: <imejfku6lvfhopegazaqvkrxciqsyevmlchugrcbsfixn6l6cn@bhgwmw4of3tw>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 23/05/2023 20:44, наб wrote:
> Package: coreutils
> Version: 9.1-1
> Version: 8.32-4+b1
> Severity: normal
> 
> Dear Maintainer,
> 
> This happens regardless of the blockdev size:
>    $ split -n20 /dev/loop2
>    split: /dev/loop2: cannot determine file size: Value too large for defined data type
> and with
>    $ split -n3 /dev/full
>    split: /dev/full: cannot determine file size: Value too large for defined data type
> the normal message is
>    $ cat | split -n20
>    split: -: cannot determine file size
> i.e. w/o strerror.
> Nothing's EOVERFLOW-worthy here, one'd think.
> 
> However:
>    $ split -n20
>    split: -: cannot determine file size
>    $ split -n20 /dev/pts/0
>    split: /dev/pts/0: cannot determine file size
>    $ split -n20 /dev/full
>    split: /dev/full: cannot determine file size: Value too large for defined data type
>    $ split -n20 /dev/zero
>    split: /dev/zero: cannot determine file size: Value too large for defined data type
>    $ split -n20 /dev/rfkill
>    split: /dev/rfkill: cannot determine file size
> so normal unseekable files get no strerror,
> /dev/full and /dev/zero are seekable and somehow yield EOVERFLOWs as well.
> 
> Oddly:
>    $ split -n20 /dev/autofs
>    split: /dev/autofs: cannot determine file size: Invalid argument
> but /dev/autofs is seekable, and only EINVALs on read()s.
> 
> Also oddly:
>    $ split -n20 /dev/null
> just works.
> Is it hard-coded somehow? This isn't noted in the manual.

This has all changed in coreutils 9.2 with:
https://github.com/coreutils/coreutils/commit/aa266f1b3

That causes data to be read, rather than depending on lseek.

cheers,
Pádraig

Send a report that this bug log contains spam.

Debian bug tracking system administrator <[email protected]>. Last modified: Tue May 13 11:13:42 2025; Machine Name: buxtehude

Debian Bug tracking system

Debbugs is free software and licensed under the terms of the GNU General Public License version 2. The current version can be obtained from https://bugs.debian.org/debbugs-source/.

Copyright © 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson, 2005-2017 Don Armstrong, and many other contributors.