From unknown Fri Sep 12 04:45:20 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#18316 <18316@debbugs.gnu.org> To: bug#18316 <18316@debbugs.gnu.org> Subject: Status: [PATCH] warn on too large file copies Reply-To: bug#18316 <18316@debbugs.gnu.org> Date: Fri, 12 Sep 2025 11:45:20 +0000 retitle 18316 [PATCH] warn on too large file copies reassign 18316 coreutils submitter 18316 adamjsho@gmail.com severity 18316 normal tag 18316 fixed patch thanks From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 22 11:57:35 2014 Received: (at submit) by debbugs.gnu.org; 22 Aug 2014 15:57:35 +0000 Received: from localhost ([127.0.0.1]:49691 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKrDa-0005Qn-IL for submit@debbugs.gnu.org; Fri, 22 Aug 2014 11:57:35 -0400 Received: from eggs.gnu.org ([208.118.235.92]:60840) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKrCt-0005P2-8A for submit@debbugs.gnu.org; Fri, 22 Aug 2014 11:56:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XKrCf-00013K-6u for submit@debbugs.gnu.org; Fri, 22 Aug 2014 11:56:46 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:54045) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XKrCf-00013G-4M for submit@debbugs.gnu.org; Fri, 22 Aug 2014 11:56:37 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34274) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XKrCV-0002Tx-TU for bug-coreutils@gnu.org; Fri, 22 Aug 2014 11:56:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XKrCM-000107-Sc for bug-coreutils@gnu.org; Fri, 22 Aug 2014 11:56:27 -0400 Received: from mail-we0-x235.google.com ([2a00:1450:400c:c03::235]:59142) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XKrCM-0000zr-Ml for bug-coreutils@gnu.org; Fri, 22 Aug 2014 11:56:18 -0400 Received: by mail-we0-f181.google.com with SMTP id k48so10658952wev.26 for ; Fri, 22 Aug 2014 08:56:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:reply-to:to:date:content-type:mime-version; bh=sf0PJq+CMxBypfOYi06SfsOzWjCMc927t2TvGdAjibY=; b=KgI6GlDmeN1Zff5kO2cDjj7lely7GqMHRY2W3lx9sTJPkcbEK0GVn96ycZijZ4T2pE 3sK14MkZm5wXD4dboad+ipoOm7VeLQsMfTTkzC/8ctvMqc4+V/cWVBGfxiPcaq3HEYiP og7q4g8qUuG2XIag7XC/0bLvySV3YoWpXWYhusFWNSv6CLtLHL9CeYuRYc1ClpMQ3psr wBQ0kVE4/0WdPUMVTjk/xwOo4BQnvVZacS5cESn00Qbteuxo3nVZrRTGbbH9/OEoi+cy sZ+9LfFmBi6xtE6P5N+UXvJk/v75hfl3O3f3zifCUr8EH+TzpDH5+DFPURdF9PH9gMZL A+JQ== X-Received: by 10.194.57.237 with SMTP id l13mr3937501wjq.102.1408722977221; Fri, 22 Aug 2014 08:56:17 -0700 (PDT) Received: from [10.0.0.2] (host81-135-133-51.range81-135.btcentralplus.com. [81.135.133.51]) by mx.google.com with ESMTPSA id ej10sm32517444wib.12.2014.08.22.08.56.14 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Fri, 22 Aug 2014 08:56:15 -0700 (PDT) Message-ID: <1408722973.2576.26.camel@localhost.localdomain> Subject: [PATCH] warn on too large file copies From: Adam To: bug-coreutils@gnu.org Date: Fri, 22 Aug 2014 16:56:13 +0100 Content-Type: multipart/mixed; boundary="=-KwSlZwaP1cHCH3u2RCnJ" X-Mailer: Evolution 3.10.4 (3.10.4-3.fc20) Mime-Version: 1.0 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Fri, 22 Aug 2014 11:57:32 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adamjsho@gmail.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) --=-KwSlZwaP1cHCH3u2RCnJ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit When files are being copied, they can hit the following loop: while (max_n_read) { ... // return true if file finishes copying // return false if error occurs // copy some file // deduct bytes copied from max_n_read ... } return true; If max_n_read reaches 0, the copy does not return a warning or a failure but instead returns that the copy completed successfully. I believe when copying files as large as these, if the maximum transfer were to be reached then the copy should not return false (as this will delete the failed destination file), but instead produce a warning and return true. I have attached a patch against the git master. Please review and consider it's inclusion. I apologise if there is an issue with this report as it is my first time submitting a patch to coreutils. Thanks, Adam Shore --=-KwSlZwaP1cHCH3u2RCnJ Content-Disposition: attachment; filename="file_too_large_warning.patch" Content-Type: text/x-patch; name="file_too_large_warning.patch"; charset="UTF-8" Content-Transfer-Encoding: 7bit Submitted by: Adam Shore Date: 2014-08-22 Inital Package Version: 8.23 Description: Adds warning when copying files too large diff --git a/src/copy.c b/src/copy.c index 26d5bdd..64e1d61 100644 --- a/src/copy.c +++ b/src/copy.c @@ -226,6 +226,10 @@ sparse_copy (int src_fd, int dest_fd, char *buf, size_t buf_size, *last_write_made_hole = make_hole; } + if (!max_n_read) + error (0, 0, _("warning: could not copy all of %s, file too large"), + quote (src_name)); + return true; } --=-KwSlZwaP1cHCH3u2RCnJ-- From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 22 12:36:30 2014 Received: (at 18316) by debbugs.gnu.org; 22 Aug 2014 16:36:30 +0000 Received: from localhost ([127.0.0.1]:49696 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKrpF-0006Qc-Gw for submit@debbugs.gnu.org; Fri, 22 Aug 2014 12:36:29 -0400 Received: from smtp.cs.ucla.edu ([131.179.128.62]:56636) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKrpC-0006QN-8o for 18316@debbugs.gnu.org; Fri, 22 Aug 2014 12:36:27 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 1A601A60003; Fri, 22 Aug 2014 09:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYK+VN-kFYGN; Fri, 22 Aug 2014 09:36:11 -0700 (PDT) Received: from [192.168.1.9] (pool-71-177-17-123.lsanca.dsl-w.verizon.net [71.177.17.123]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 662FFA60049; Fri, 22 Aug 2014 09:36:11 -0700 (PDT) Message-ID: <53F7717B.5080608@cs.ucla.edu> Date: Fri, 22 Aug 2014 09:36:11 -0700 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: adamjsho@gmail.com, 18316@debbugs.gnu.org Subject: Re: bug#18316: [PATCH] warn on too large file copies References: <1408722973.2576.26.camel@localhost.localdomain> In-Reply-To: <1408722973.2576.26.camel@localhost.localdomain> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -3.0 (---) X-Debbugs-Envelope-To: 18316 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.0 (---) Adam wrote: > I believe when copying files as large as these, if the maximum transfer > were to be reached then the copy should not return false (as this will > delete the failed destination file), but instead produce a warning and > return true. Sorry, I don't see the bug. max_n_nread is normally UINTMAX_MAX, which is effectively infinity, so it shouldn't be an issue then. When max_n_read is less than UINTMAX_MAX, we're copying one extent of a sparse file, and it's not an error to read less than the extent we expect to find, as that can happen when the file changed as we read it. Perhaps cp should optionally warn if the input file changes while we read it, but that's a bigger change and one that should be done elsewhere. From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 22 12:42:07 2014 Received: (at 18316) by debbugs.gnu.org; 22 Aug 2014 16:42:07 +0000 Received: from localhost ([127.0.0.1]:49702 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKrug-0006b4-HQ for submit@debbugs.gnu.org; Fri, 22 Aug 2014 12:42:07 -0400 Received: from mail5.vodafone.ie ([213.233.128.176]:6273) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKruc-0006aX-1j for 18316@debbugs.gnu.org; Fri, 22 Aug 2014 12:42:03 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAJxx91NtT3SS/2dsb2JhbAANTIczzg+DHwGBJYR7AQEEIw8BRhALDQsCAgUWCwICCQMCAQIBRRADAQcBAYhDrlB4lREXgSyOIAcWgmOBUwEEpCGPGB6BXYM6AQEB Received: from unknown (HELO [192.168.1.41]) ([109.79.116.146]) by mail3.vodafone.ie with ESMTP; 22 Aug 2014 17:41:55 +0100 Message-ID: <53F772D1.4000103@draigBrady.com> Date: Fri, 22 Aug 2014 17:41:53 +0100 From: =?UTF-8?B?UMOhZHJhaWcgQnJhZHk=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: adamjsho@gmail.com Subject: Re: bug#18316: [PATCH] warn on too large file copies References: <1408722973.2576.26.camel@localhost.localdomain> In-Reply-To: <1408722973.2576.26.camel@localhost.localdomain> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 18316 Cc: 18316@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) On 08/22/2014 04:56 PM, Adam wrote: > When files are being copied, they can hit the following loop: > > while (max_n_read) > { > ... > // return true if file finishes copying > // return false if error occurs > // copy some file > // deduct bytes copied from max_n_read > ... > } > > return true; > > If max_n_read reaches 0, the copy does not return a warning or a failure > but instead returns that the copy completed successfully. > > I believe when copying files as large as these, if the maximum transfer > were to be reached then the copy should not return false (as this will > delete the failed destination file), but instead produce a warning and > return true. > > I have attached a patch against the git master. Please review and > consider it's inclusion. > > I apologise if there is an issue with this report as it is my first time > submitting a patch to coreutils. I think that would issue a false warning when using extent_copy(), which is used on sparse files on many file systems. In the other case UINTMAX_MAX is passed and so should be large enough for any regular file, though I suppose this is a theoretical concern if cp was being used between devices for example. I.E. it would stop without any error after about 19EB on both 32 and 64 bit platforms. That's the case you're trying to avoid here right, or is there a more practical concern? thanks, Pádraig. From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 22 13:01:16 2014 Received: (at 18316) by debbugs.gnu.org; 22 Aug 2014 17:01:16 +0000 Received: from localhost ([127.0.0.1]:49726 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKsDD-00075Y-Bt for submit@debbugs.gnu.org; Fri, 22 Aug 2014 13:01:15 -0400 Received: from mail-wg0-f46.google.com ([74.125.82.46]:63593) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKsD9-00075I-Rt for 18316@debbugs.gnu.org; Fri, 22 Aug 2014 13:01:13 -0400 Received: by mail-wg0-f46.google.com with SMTP id m15so10641100wgh.17 for <18316@debbugs.gnu.org>; Fri, 22 Aug 2014 10:01:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:reply-to:to:date:content-type:mime-version :content-transfer-encoding; bh=l7ftrj1NXm9N4TDgpfa2wIg+CcvdrnbOLLM+cKkxtX4=; b=EpbFWaBxkvOgsz3iaprDes5cuBglRgitOafBI/50Ze26Qve5YDfpHyARzE4LZir+xp CtYplQobwG3FGWcMgThgbPmvh6kqtycuax3DYG9U2IZIOz1p7jLSv9CR+0OaLc3gs5OQ jZS+a4Lq8smCqLyHBHGyLGeJV/Vur/T3NDxUoY5sWE8zTd6FIS/EXsMMzjvbVRzxzVHC mf4ddGuPk+yG+8E8dOuEMEGs9iE5qr4F+dZgzulXKv3PAl9e1Ptt1No8uQjVKfqms09e OeusoTfBouCGHg72FiFiL/6mWEQ0fm29Fq9Wyb3DGS84gdk0WpFptLn+0yFZ9r+vyi0T XMyQ== X-Received: by 10.180.87.231 with SMTP id bb7mr12075352wib.63.1408726865872; Fri, 22 Aug 2014 10:01:05 -0700 (PDT) Received: from [10.0.0.2] (host81-135-133-51.range81-135.btcentralplus.com. [81.135.133.51]) by mx.google.com with ESMTPSA id el3sm33016333wib.24.2014.08.22.10.01.03 for <18316@debbugs.gnu.org> (version=SSLv3 cipher=RC4-SHA bits=128/128); Fri, 22 Aug 2014 10:01:04 -0700 (PDT) Message-ID: <1408726862.2576.35.camel@localhost.localdomain> Subject: Re: bug#18316: [PATCH] warn on too large file copies From: Adam To: 18316@debbugs.gnu.org Date: Fri, 22 Aug 2014 18:01:02 +0100 Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4 (3.10.4-3.fc20) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 18316 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adamjsho@gmail.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > In the other case UINTMAX_MAX is passed and so should be large > enough for any regular file, though I suppose this is a > theoretical concern if cp was being used between devices for example. > I.E. it would stop without any error after about 19EB on > both 32 and 64 bit platforms. That's the case you're trying to > avoid here right, or is there a more practical concern? Yes, this is what I meant. I know it's a rare scenario however I thought I would still mention it as I can not see harm in adding a check in. Apologies for any confusion. Thanks, Adam From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 22 14:09:57 2014 Received: (at 18316) by debbugs.gnu.org; 22 Aug 2014 18:09:57 +0000 Received: from localhost ([127.0.0.1]:49772 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKtHg-0000M8-JV for submit@debbugs.gnu.org; Fri, 22 Aug 2014 14:09:57 -0400 Received: from smtp.cs.ucla.edu ([131.179.128.62]:32900) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKtHe-0000Ls-2g for 18316@debbugs.gnu.org; Fri, 22 Aug 2014 14:09:55 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id DF8D9A60003; Fri, 22 Aug 2014 11:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MeAklWK1ufc0; Fri, 22 Aug 2014 11:09:39 -0700 (PDT) Received: from [192.168.1.9] (pool-71-177-17-123.lsanca.dsl-w.verizon.net [71.177.17.123]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 64254A60049; Fri, 22 Aug 2014 11:09:39 -0700 (PDT) Message-ID: <53F78763.40502@cs.ucla.edu> Date: Fri, 22 Aug 2014 11:09:39 -0700 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: adamjsho@gmail.com, 18316@debbugs.gnu.org Subject: Re: bug#18316: [PATCH] warn on too large file copies References: <1408722973.2576.26.camel@localhost.localdomain> <1408726862.2576.35.camel@localhost.localdomain> In-Reply-To: <1408726862.2576.35.camel@localhost.localdomain> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -3.0 (---) X-Debbugs-Envelope-To: 18316 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.0 (---) Adam wrote: > I know it's a rare scenario The next time you copy a file containing 19 exabytes let us know. :-) If we're going to fix this, I suggest removing the limit entirely; that's better than generating a warning if the limit is gone past. I expect there are plenty of places in the code that stop working after 2**63 bytes, and I'd focus on them first. From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 22 15:12:13 2014 Received: (at 18316) by debbugs.gnu.org; 22 Aug 2014 19:12:13 +0000 Received: from localhost ([127.0.0.1]:49782 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKuFv-00026C-WF for submit@debbugs.gnu.org; Fri, 22 Aug 2014 15:12:12 -0400 Received: from smtp.cs.ucla.edu ([131.179.128.62]:35796) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKuFs-00025p-KU for 18316@debbugs.gnu.org; Fri, 22 Aug 2014 15:12:09 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 485EF39E801E; Fri, 22 Aug 2014 12:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivvtBFUkub51; Fri, 22 Aug 2014 12:11:57 -0700 (PDT) Received: from [192.168.1.9] (pool-71-177-17-123.lsanca.dsl-w.verizon.net [71.177.17.123]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 2E95D39E8016; Fri, 22 Aug 2014 12:11:57 -0700 (PDT) Message-ID: <53F795FC.6030302@cs.ucla.edu> Date: Fri, 22 Aug 2014 12:11:56 -0700 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: =?UTF-8?B?UMOhZHJhaWcgQnJhZHk=?= , adamjsho@gmail.com Subject: Re: bug#18316: [PATCH] warn on too large file copies References: <1408722973.2576.26.camel@localhost.localdomain> <53F772D1.4000103@draigBrady.com> In-Reply-To: <53F772D1.4000103@draigBrady.com> Content-Type: multipart/mixed; boundary="------------070204020608010804010407" X-Spam-Score: -3.0 (---) X-Debbugs-Envelope-To: 18316 Cc: 18316@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.0 (---) This is a multi-part message in MIME format. --------------070204020608010804010407 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit That reminds me, we should be avoiding types like uint64_t unless they're really needed. The fiemap code is bound tightly to the Linux kernel so I guess uint64_t is OK there, but the portable code should use higher-level types like off_t. I installed the attached patch. No doubt further cleanups like this could be made but one thing at a time. --------------070204020608010804010407 Content-Type: text/plain; charset=UTF-8; name="0001-maint-avoid-int64_t-and-similar-types-unless-they-re.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename*0="0001-maint-avoid-int64_t-and-similar-types-unless-they-re.pa"; filename*1="tch" RnJvbSA0NjQxOGVjZWMwNGNhNjE2NDdkNjc1MGEwYTBmZTg2MmYwYWU2OWMxIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBQYXVsIEVnZ2VydCA8ZWdnZXJ0QGNzLnVjbGEuZWR1 PgpEYXRlOiBGcmksIDIyIEF1ZyAyMDE0IDEyOjA3OjExIC0wNzAwClN1YmplY3Q6IFtQQVRD SF0gbWFpbnQ6IGF2b2lkIGludDY0X3QgYW5kIHNpbWlsYXIgdHlwZXMgdW5sZXNzIHRoZXkn cmUgbmVlZGVkCgpDMTEgZG9lc24ndCByZXF1aXJlIHRoZW0sIGV2ZW4gUE9TSVggZG9lc24n dCBzdHJpY3RseSByZXF1aXJlIHRoZQo2NC1iaXQgdmVyc2lvbnMsIGFuZCBpdCBtYWtlcyB0 aGUgY29kZSBhIGJpdCBjbGVhcmVyIGlmIHRoZXkncmUKdXNlZCBvbmx5IHdoZW4gbmVlZGVk LgoqIHNyYy9jb3B5LmMgKHdyaXRlX3plcm9zLCBleHRlbnRfY29weSk6Ciogc3JjL2V4dGVu dC1zY2FuLmggKHN0cnVjdCBleHRlbnRfaW5mby5leHRfbGVuZ3RoKToKVXNlIG9mZl90LCBu b3QgdWludDY0X3QsIGZvciBhIHZhbHVlIGRlcml2ZWQgZnJvbSBhIGZpbGUgb2Zmc2V0Lgoq IHNyYy9leHRlbnQtc2Nhbi5oIChzdHJ1Y3QgZXh0ZW50X2luZm8uZXh0X2ZsYWdzKQpQcmVm ZXIgcGxhaW4gdW5zaWduZWQgaW50IHRvIHVpbnQzMl90IHdoZXJlIGVpdGhlciB3aWxsIGRv Lgooc3RydWN0IGV4dGVudF9zY2FuLmVpX2NvdW50KToKVXNlIHNpemVfdCwgbm90IHVpbnQz Ml90LCBmb3IgYSB2YWx1ZSBib3VuZGVkIGJ5IFNJWkVfTUFYLgoqIHNyYy9mYWN0b3IuYyAo TUFHSUM2NCwgTUFHSUM2MywgTUFHSUM2NSk6ClJlbW92ZSB1bm5lY2Vzc2FyeSBjYXN0cyB0 byB1aW50NjRfdC4KLS0tCiBzcmMvY29weS5jICAgICAgICB8IDEwICsrKysrLS0tLS0KIHNy Yy9leHRlbnQtc2Nhbi5oIHwgIDggKysrKy0tLS0KIHNyYy9mYWN0b3IuYyAgICAgIHwgIDYg KysrLS0tCiAzIGZpbGVzIGNoYW5nZWQsIDEyIGluc2VydGlvbnMoKyksIDEyIGRlbGV0aW9u cygtKQoKZGlmZiAtLWdpdCBhL3NyYy9jb3B5LmMgYi9zcmMvY29weS5jCmluZGV4IDI2ZDVi ZGQuLmE5NTYxYzYgMTAwNjQ0Ci0tLSBhL3NyYy9jb3B5LmMKKysrIGIvc3JjL2NvcHkuYwpA QCAtMjUxLDcgKzI1MSw3IEBAIGNsb25lX2ZpbGUgKGludCBkZXN0X2ZkLCBpbnQgc3JjX2Zk KQogLyogV3JpdGUgTl9CWVRFUyB6ZXJvIGJ5dGVzIHRvIGZpbGUgZGVzY3JpcHRvciBGRC4g IFJldHVybiB0cnVlIGlmIHN1Y2Nlc3NmdWwuCiAgICBVcG9uIHdyaXRlIGZhaWx1cmUsIHNl dCBlcnJubyBhbmQgcmV0dXJuIGZhbHNlLiAgKi8KIHN0YXRpYyBib29sCi13cml0ZV96ZXJv cyAoaW50IGZkLCB1aW50NjRfdCBuX2J5dGVzKQord3JpdGVfemVyb3MgKGludCBmZCwgb2Zm X3Qgbl9ieXRlcykKIHsKICAgc3RhdGljIGNoYXIgKnplcm9zOwogICBzdGF0aWMgc2l6ZV90 IG56ID0gSU9fQlVGU0laRTsKQEAgLTI3Miw3ICsyNzIsNyBAQCB3cml0ZV96ZXJvcyAoaW50 IGZkLCB1aW50NjRfdCBuX2J5dGVzKQogCiAgIHdoaWxlIChuX2J5dGVzKQogICAgIHsKLSAg ICAgIHVpbnQ2NF90IG4gPSBNSU4gKG56LCBuX2J5dGVzKTsKKyAgICAgIHNpemVfdCBuID0g TUlOIChueiwgbl9ieXRlcyk7CiAgICAgICBpZiAoKGZ1bGxfd3JpdGUgKGZkLCB6ZXJvcywg bikpICE9IG4pCiAgICAgICAgIHJldHVybiBmYWxzZTsKICAgICAgIG5fYnl0ZXMgLT0gbjsK QEAgLTI5Niw3ICsyOTYsNyBAQCBleHRlbnRfY29weSAoaW50IHNyY19mZCwgaW50IGRlc3Rf ZmQsIGNoYXIgKmJ1Ziwgc2l6ZV90IGJ1Zl9zaXplLAogewogICBzdHJ1Y3QgZXh0ZW50X3Nj YW4gc2NhbjsKICAgb2ZmX3QgbGFzdF9leHRfc3RhcnQgPSAwOwotICB1aW50NjRfdCBsYXN0 X2V4dF9sZW4gPSAwOworICBvZmZfdCBsYXN0X2V4dF9sZW4gPSAwOwogCiAgIC8qIEtlZXAg dHJhY2sgb2YgdGhlIG91dHB1dCBwb3NpdGlvbi4KICAgICAgV2UgbWF5IG5lZWQgdGhpcyBh dCB0aGUgZW5kLCBmb3IgYSBmaW5hbCBmdHJ1bmNhdGUuICAqLwpAQCAtMzMwLDggKzMzMCw4 IEBAIGV4dGVudF9jb3B5IChpbnQgc3JjX2ZkLCBpbnQgZGVzdF9mZCwgY2hhciAqYnVmLCBz aXplX3QgYnVmX3NpemUsCiAgICAgICBmb3IgKGkgPSAwOyBpIDwgc2Nhbi5laV9jb3VudCB8 fCBlbXB0eV9leHRlbnQ7IGkrKykKICAgICAgICAgewogICAgICAgICAgIG9mZl90IGV4dF9z dGFydDsKLSAgICAgICAgICB1aW50NjRfdCBleHRfbGVuOwotICAgICAgICAgIHVpbnQ2NF90 IGhvbGVfc2l6ZTsKKyAgICAgICAgICBvZmZfdCBleHRfbGVuOworICAgICAgICAgIG9mZl90 IGhvbGVfc2l6ZTsKIAogICAgICAgICAgIGlmIChpIDwgc2Nhbi5laV9jb3VudCkKICAgICAg ICAgICAgIHsKZGlmZiAtLWdpdCBhL3NyYy9leHRlbnQtc2Nhbi5oIGIvc3JjL2V4dGVudC1z Y2FuLmgKaW5kZXggZmE4MDAzNC4uNzMyMDJhOSAxMDA2NDQKLS0tIGEvc3JjL2V4dGVudC1z Y2FuLmgKKysrIGIvc3JjL2V4dGVudC1zY2FuLmgKQEAgLTI2LDEwICsyNiwxMCBAQCBzdHJ1 Y3QgZXh0ZW50X2luZm8KICAgb2ZmX3QgZXh0X2xvZ2ljYWw7CiAKICAgLyogRXh0ZW50IGxl bmd0aC4gICovCi0gIHVpbnQ2NF90IGV4dF9sZW5ndGg7CisgIG9mZl90IGV4dF9sZW5ndGg7 CiAKICAgLyogRXh0ZW50IGZsYWdzLCB1c2UgaXQgZm9yIEZJRU1BUCBvbmx5LCBvciBzZXQg aXQgdG8gemVyby4gICovCi0gIHVpbnQzMl90IGV4dF9mbGFnczsKKyAgdW5zaWduZWQgaW50 IGV4dF9mbGFnczsKIH07CiAKIC8qIFN0cnVjdHVyZSB1c2VkIHRvIHJlc2VydmUgZXh0ZW50 IHNjYW4gaW5mb3JtYXRpb24gcGVyIGZpbGUuICAqLwpAQCAtNDIsMTAgKzQyLDEwIEBAIHN0 cnVjdCBleHRlbnRfc2NhbgogICBvZmZfdCBzY2FuX3N0YXJ0OwogCiAgIC8qIEZsYWdzIHRv IHVzZSBmb3Igc2Nhbi4gICovCi0gIHVpbnQzMl90IGZtX2ZsYWdzOworICB1bnNpZ25lZCBp bnQgZm1fZmxhZ3M7CiAKICAgLyogSG93IG1hbnkgZXh0ZW50IGluZm8gcmV0dXJuZWQgZm9y IGEgc2Nhbi4gICovCi0gIHVpbnQzMl90IGVpX2NvdW50OworICBzaXplX3QgZWlfY291bnQ7 CiAKICAgLyogSWYgdHJ1ZSwgZmFsbCBiYWNrIHRvIGEgbm9ybWFsIGNvcHksIGVpdGhlciBz ZXQgYnkgdGhlCiAgICAgIGZhaWx1cmUgb2YgaW9jdGwoMikgZm9yIEZJRU1BUCBvciBsc2Vl aygyKSB3aXRoIFNFRUtfREFUQS4gICovCmRpZmYgLS1naXQgYS9zcmMvZmFjdG9yLmMgYi9z cmMvZmFjdG9yLmMKaW5kZXggNjM5MjRkNS4uZjdiZWFlYiAxMDA2NDQKLS0tIGEvc3JjL2Zh Y3Rvci5jCisrKyBiL3NyYy9mYWN0b3IuYwpAQCAtMTgxMSw5ICsxODExLDkgQEAgaXNxcnQy ICh1aW50bWF4X3QgbmgsIHVpbnRtYXhfdCBubCkKIH0KIAogLyogTUFHSUNbTl0gaGFzIGEg Yml0IGkgc2V0IGlmZiBpIGlzIGEgcXVhZHJhdGljIHJlc2lkdWUgbW9kIE4uICovCi0jZGVm aW5lIE1BR0lDNjQgKCh1aW50NjRfdCkgMHgwMjAyMDIxMjAyMDMwMjEzVUxMKQotI2RlZmlu ZSBNQUdJQzYzICgodWludDY0X3QpIDB4MDQwMjQ4MzAxMjQ1MDI5M1VMTCkKLSNkZWZpbmUg TUFHSUM2NSAoKHVpbnQ2NF90KSAweDIxOGEwMTk4NjYwMTQ2MTNVTEwpCisjZGVmaW5lIE1B R0lDNjQgMHgwMjAyMDIxMjAyMDMwMjEzVUxMCisjZGVmaW5lIE1BR0lDNjMgMHgwNDAyNDgz MDEyNDUwMjkzVUxMCisjZGVmaW5lIE1BR0lDNjUgMHgyMThhMDE5ODY2MDE0NjEzVUxMCiAj ZGVmaW5lIE1BR0lDMTEgMHgyM2IKIAogLyogUmV0dXJuIHRoZSBzcXVhcmUgcm9vdCBpZiB0 aGUgaW5wdXQgaXMgYSBzcXVhcmUsIG90aGVyd2lzZSAwLiAqLwotLSAKMS45LjMKCg== --------------070204020608010804010407-- From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 22 15:38:18 2014 Received: (at 18316) by debbugs.gnu.org; 22 Aug 2014 19:38:18 +0000 Received: from localhost ([127.0.0.1]:49786 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKufC-0002qA-31 for submit@debbugs.gnu.org; Fri, 22 Aug 2014 15:38:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:30216) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKuf8-0002px-B5 for 18316@debbugs.gnu.org; Fri, 22 Aug 2014 15:38:15 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s7MJc5ZY025038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 22 Aug 2014 15:38:05 -0400 Received: from [10.3.113.160] (ovpn-113-160.phx2.redhat.com [10.3.113.160]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s7MJc4Jk017956; Fri, 22 Aug 2014 15:38:04 -0400 Message-ID: <53F79C1C.8030400@redhat.com> Date: Fri, 22 Aug 2014 13:38:04 -0600 From: Eric Blake Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Paul Eggert , adamjsho@gmail.com, 18316@debbugs.gnu.org Subject: Re: bug#18316: [PATCH] warn on too large file copies References: <1408722973.2576.26.camel@localhost.localdomain> <1408726862.2576.35.camel@localhost.localdomain> <53F78763.40502@cs.ucla.edu> In-Reply-To: <53F78763.40502@cs.ucla.edu> OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fL4I9iB1semBVi6enQv1j8oNioe4E5wj1" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Spam-Score: -5.7 (-----) X-Debbugs-Envelope-To: 18316 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.7 (-----) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fL4I9iB1semBVi6enQv1j8oNioe4E5wj1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 08/22/2014 12:09 PM, Paul Eggert wrote: > Adam wrote: >> I know it's a rare scenario >=20 > The next time you copy a file containing 19 exabytes let us know. :-) By the way, even at a lightning-fast rate of a gigabyte a second, such a copy wouldn't complete in your lifetime. >=20 > If we're going to fix this, I suggest removing the limit entirely; > that's better than generating a warning if the limit is gone past. I > expect there are plenty of places in the code that stop working after > 2**63 bytes, and I'd focus on them first. The size of 2**63 is so huge that it is as good as unlimited, for anything we can do in a finite lifetime, and we don't have to bend over backwards trying to treat it as an artificial limitation. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --fL4I9iB1semBVi6enQv1j8oNioe4E5wj1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg iQEcBAEBCAAGBQJT95wcAAoJEKeha0olJ0NqzkQH/0xF+uNyD9c9rQcKmeifWU4J PXjmRBQZn/l7U7ln9byx7v7NjMDUgfSid5y8l4IgwjNeiewlstx+NYl9DT+zgQs+ oEUS9dEXDvi5f66hB+yULFCzZrBHPBUAM2pvfqSEUkbLeNNjAVlZHZuapEOz4TL+ tqkFLbSjcwnP/Kf/TXakPJ2TjRDpiicgvwRjTHbleP0zGpcDVwMxYLsyULevYgXF ap1fifs2gamueFwJShubIioHL71M7lXdX3GVeEhYzUjNWPxoLgD9A7dG9OXHZXId 6y2UdlflCo5OV2eIFmgwh6zbfIuHMH0XJ99FmntFxSLIWks+Zt39gowr+5gqGZo= =fm51 -----END PGP SIGNATURE----- --fL4I9iB1semBVi6enQv1j8oNioe4E5wj1-- From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 22 19:38:28 2014 Received: (at 18316) by debbugs.gnu.org; 22 Aug 2014 23:38:29 +0000 Received: from localhost ([127.0.0.1]:49859 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKyPb-00016K-Sf for submit@debbugs.gnu.org; Fri, 22 Aug 2014 19:38:28 -0400 Received: from mail4.vodafone.ie ([213.233.128.170]:23999) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKyPY-00015y-GC for 18316@debbugs.gnu.org; Fri, 22 Aug 2014 19:38:26 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsBADbT91NtT3SS/2dsb2JhbAANTA6EKYJ80TEBgSWEegEBAQQjBAsBRhALDQQDAQIBAgIFFgsCAgkDAgECAT0IBg0BBQIBAYhDrnl4lQQXgSyOIAeCeYFTAQSPE5UOjxgegRpDa4JPAQEB Received: from unknown (HELO [192.168.1.41]) ([109.79.116.146]) by mail3.vodafone.ie with ESMTP; 23 Aug 2014 00:38:16 +0100 Message-ID: <53F7D468.3040907@draigBrady.com> Date: Sat, 23 Aug 2014 00:38:16 +0100 From: =?UTF-8?B?UMOhZHJhaWcgQnJhZHk=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Paul Eggert Subject: Re: bug#18316: [PATCH] warn on too large file copies References: <1408722973.2576.26.camel@localhost.localdomain> <53F772D1.4000103@draigBrady.com> <53F795FC.6030302@cs.ucla.edu> In-Reply-To: <53F795FC.6030302@cs.ucla.edu> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 18316 Cc: adamjsho@gmail.com, 18316@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) On 08/22/2014 08:11 PM, Paul Eggert wrote: > From 46418ecec04ca61647d6750a0a0fe862f0ae69c1 Mon Sep 17 00:00:00 2001 > From: Paul Eggert > Date: Fri, 22 Aug 2014 12:07:11 -0700 > Subject: [PATCH] maint: avoid int64_t and similar types unless they're needed > > C11 doesn't require them, even POSIX doesn't strictly require the > 64-bit versions, and it makes the code a bit clearer if they're > used only when needed. > * src/copy.c (write_zeros, extent_copy): > * src/extent-scan.h (struct extent_info.ext_length): > Use off_t, not uint64_t, for a value derived from a file offset. > * src/extent-scan.h (struct extent_info.ext_flags) > Prefer plain unsigned int to uint32_t where either will do. > (struct extent_scan.ei_count): > Use size_t, not uint32_t, for a value bounded by SIZE_MAX. > * src/factor.c (MAGIC64, MAGIC63, MAGIC65): > Remove unnecessary casts to uint64_t. > --- > src/copy.c | 10 +++++----- > src/extent-scan.h | 8 ++++---- > src/factor.c | 6 +++--- > 3 files changed, 12 insertions(+), 12 deletions(-) > > diff --git a/src/copy.c b/src/copy.c > index 26d5bdd..a9561c6 100644 > --- a/src/copy.c > +++ b/src/copy.c > @@ -251,7 +251,7 @@ clone_file (int dest_fd, int src_fd) > /* Write N_BYTES zero bytes to file descriptor FD. Return true if successful. > Upon write failure, set errno and return false. */ > static bool > -write_zeros (int fd, uint64_t n_bytes) > +write_zeros (int fd, off_t n_bytes) > { > static char *zeros; > static size_t nz = IO_BUFSIZE; > @@ -272,7 +272,7 @@ write_zeros (int fd, uint64_t n_bytes) > > while (n_bytes) > { > - uint64_t n = MIN (nz, n_bytes); > + size_t n = MIN (nz, n_bytes); > if ((full_write (fd, zeros, n)) != n) > return false; > n_bytes -= n; The above are fine and good. > @@ -296,7 +296,7 @@ extent_copy (int src_fd, int dest_fd, char *buf, size_t buf_size, > { > struct extent_scan scan; > off_t last_ext_start = 0; > - uint64_t last_ext_len = 0; > + off_t last_ext_len = 0; > > /* Keep track of the output position. > We may need this at the end, for a final ftruncate. */ > @@ -330,8 +330,8 @@ extent_copy (int src_fd, int dest_fd, char *buf, size_t buf_size, > for (i = 0; i < scan.ei_count || empty_extent; i++) > { > off_t ext_start; > - uint64_t ext_len; > - uint64_t hole_size; > + off_t ext_len; > + off_t hole_size; > > if (i < scan.ei_count) > { > diff --git a/src/extent-scan.h b/src/extent-scan.h > index fa80034..73202a9 100644 > --- a/src/extent-scan.h > +++ b/src/extent-scan.h > @@ -26,10 +26,10 @@ struct extent_info > off_t ext_logical; > > /* Extent length. */ > - uint64_t ext_length; > + off_t ext_length; The off_t changes assume we compile with -D_FILE_OFFSET_BITS=64 on 32 bit, which we do, but it's a bit coupled. > > /* Extent flags, use it for FIEMAP only, or set it to zero. */ > - uint32_t ext_flags; > + unsigned int ext_flags; > }; > > /* Structure used to reserve extent scan information per file. */ > @@ -42,10 +42,10 @@ struct extent_scan > off_t scan_start; > > /* Flags to use for scan. */ > - uint32_t fm_flags; > + unsigned int fm_flags; We check a few low bit flags which is OK though a bit coupled, and we also merge extents if the flags are the same which could cause invalid merging on 32 bit if the flags ever expanded to 64 bits which they could theoretically do as there is reserved space for that in the fiemap structures. I suppose we could protect against that unlikely possibility with: diff --git a/src/extent-scan.c b/src/extent-scan.c index 805997a..3af8f99 100644 --- a/src/extent-scan.c +++ b/src/extent-scan.c @@ -140,6 +140,8 @@ extent_scan_read (struct extent_scan *scan) assert (fm_extents[i].fe_logical <= OFF_T_MAX - fm_extents[i].fe_length); + verify (sizeof last_ei->ext_flags >= sizeof fm_extents->fe_flags); + if (si && last_ei->ext_flags == (fm_extents[i].fe_flags & ~FIEMAP_EXTENT_LAST) && (last_ei->ext_logical + last_ei->ext_length > /* How many extent info returned for a scan. */ > - uint32_t ei_count; > + size_t ei_count; We verify ei_count within SIZE_MAX anyway so this is good. > /* If true, fall back to a normal copy, either set by the > failure of ioctl(2) for FIEMAP or lseek(2) with SEEK_DATA. */ > diff --git a/src/factor.c b/src/factor.c > index 63924d5..f7beaeb 100644 > --- a/src/factor.c > +++ b/src/factor.c > @@ -1811,9 +1811,9 @@ isqrt2 (uintmax_t nh, uintmax_t nl) > } > > /* MAGIC[N] has a bit i set iff i is a quadratic residue mod N. */ > -#define MAGIC64 ((uint64_t) 0x0202021202030213ULL) > -#define MAGIC63 ((uint64_t) 0x0402483012450293ULL) > -#define MAGIC65 ((uint64_t) 0x218a019866014613ULL) > +#define MAGIC64 0x0202021202030213ULL > +#define MAGIC63 0x0402483012450293ULL > +#define MAGIC65 0x218a019866014613ULL +1 In summary all the changes look good, though I might push the above amendment for defensive reasons. cheers, Pádraig. From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 22 20:05:27 2014 Received: (at 18316) by debbugs.gnu.org; 23 Aug 2014 00:05:27 +0000 Received: from localhost ([127.0.0.1]:49863 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKypi-0001oO-Rt for submit@debbugs.gnu.org; Fri, 22 Aug 2014 20:05:27 -0400 Received: from smtp.cs.ucla.edu ([131.179.128.62]:47173) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKypf-0001o8-FS for 18316@debbugs.gnu.org; Fri, 22 Aug 2014 20:05:24 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 3464439E801E; Fri, 22 Aug 2014 17:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5fg6pU4tkkq; Fri, 22 Aug 2014 17:05:08 -0700 (PDT) Received: from [192.168.1.9] (pool-71-177-17-123.lsanca.dsl-w.verizon.net [71.177.17.123]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 847DC39E8014; Fri, 22 Aug 2014 17:05:08 -0700 (PDT) Message-ID: <53F7DAB3.2060300@cs.ucla.edu> Date: Fri, 22 Aug 2014 17:05:07 -0700 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: =?UTF-8?B?UMOhZHJhaWcgQnJhZHk=?= Subject: Re: bug#18316: [PATCH] warn on too large file copies References: <1408722973.2576.26.camel@localhost.localdomain> <53F772D1.4000103@draigBrady.com> <53F795FC.6030302@cs.ucla.edu> <53F7D468.3040907@draigBrady.com> In-Reply-To: <53F7D468.3040907@draigBrady.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -3.0 (---) X-Debbugs-Envelope-To: 18316 Cc: adamjsho@gmail.com, 18316@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.0 (---) Pádraig Brady wrote: > + verify (sizeof last_ei->ext_flags >= sizeof fm_extents->fe_flags); Sure, that looks good. We will always use large-file compilation, so I wouldn't worry about the other thing. From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 10 11:53:16 2018 Received: (at control) by debbugs.gnu.org; 10 Oct 2018 15:53:16 +0000 Received: from localhost ([127.0.0.1]:43702 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gAGnR-0000aZ-Uf for submit@debbugs.gnu.org; Wed, 10 Oct 2018 11:53:16 -0400 Received: from mail-pl1-f176.google.com ([209.85.214.176]:43337) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gAGnQ-0000aN-Dj for control@debbugs.gnu.org; Wed, 10 Oct 2018 11:53:12 -0400 Received: by mail-pl1-f176.google.com with SMTP id 30-v6so2728944plb.10 for ; Wed, 10 Oct 2018 08:53:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:message-id:date:user-agent:mime-version:content-language :content-transfer-encoding; bh=GBwryLuVyf0v48fz8kIG9SeN9dZF9WX518JvUYXRzMs=; b=QYSiDeNW8t0owFlJ28HOKvmPYHzGSWf2nYGxZ8T1HdvbB+IiSs8G7b0o7TvChKAyCp es+SjGkYr9FZPafWGeYCYJR7LRSdLM/UTEWcTztXQUDzjVxUUEwBAiOsUrGmMyIZRW39 Rs2GHVMvRrgHZnnJP7rH6nTnnsxyoD1grbpvPE+MKh8Gw2+YpRjuCPv6RTVSskmQeLr7 S8GqjZ+Lfz5pe1Aoy40EJXZTH9AkbUbq+mpxuvBlvIYHVNe/Wn5FQc/CgOwBPnJG8FUi XZNeHI6sIUk4L8L4m3oOY66RsbOWPx6IDGTn9kN0b6v1gmfNwEb+gOvkJg8cNI099ANH 8esA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=GBwryLuVyf0v48fz8kIG9SeN9dZF9WX518JvUYXRzMs=; b=PqU1gVt9I6HM61N1xSR+ea6A7Hp+Py3CQnde9n0rpIcYhkmqSK9XlEHH6PCwTEilpt 55PyhHW/BxksjObIQ7zf6PGmtdwLpa9ijau67sFhYEo1yFcROElR/gsLCX6mt+xda75R OlkcAqrs+G4gZkWqwYbiuh9lTCnco6pNJwmsfNolmums26YMlmBG/QaXEqeI4R2Ar1Q2 Dlh4d7cpt08BKCZUqVRnmkMRHLztTh3cJg3RhmQpbx3ivq8SrFjXELNbctczhk72iDtK lyqCFNgIYa/By9SXpFMT1V2evSM/12RcVmzMOy95tBQF4cXH83l4vdJoWKh15xa+XDWO x6Bw== X-Gm-Message-State: ABuFfojCxaB3839ouAoYHA/CAWS/F07PKTVvvVUU5cC9jU9mhCcg5C5F eBG9j2eb27aH49af5QOy+05XGZMM+q4= X-Google-Smtp-Source: ACcGV63be+PgrpFXoZPsRxQsyfXfn0CMPG3CQsuaMS6Yy5+2z2tfPnEZ9Vt4BMc8Lkgx/+L/DKzPfQ== X-Received: by 2002:a17:902:b482:: with SMTP id y2-v6mr315322plr.322.1539186785953; Wed, 10 Oct 2018 08:53:05 -0700 (PDT) Received: from tomato.housegordon.com (moose.housegordon.com. [184.68.105.38]) by smtp.googlemail.com with ESMTPSA id b62-v6sm35892109pfa.159.2018.10.10.08.53.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Oct 2018 08:53:04 -0700 (PDT) To: control@debbugs.gnu.org From: Assaf Gordon Message-ID: <85104995-e015-d1c8-a457-7ac3b4349742@gmail.com> Date: Wed, 10 Oct 2018 09:53:03 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 2.0 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: tags 18062 fixed close 18062 tags 16940 fixed close 16940 tags 17590 fixed close 17590 [...] Content analysis details: (2.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [209.85.214.176 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (assafgordon[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.8 MISSING_SUBJECT Missing Subject: header 0.2 NO_SUBJECT Extra score for no subject X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) tags 18062 fixed close 18062 tags 16940 fixed close 16940 tags 17590 fixed close 17590 tags 18316 fixed close 18316 tags 18531 fixed close 18531 From unknown Fri Sep 12 04:45:20 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Thu, 08 Nov 2018 12:24:05 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator