From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CUXwq-0005Vu-Fm for qemu-devel@nongnu.org; Wed, 17 Nov 2004 17:06:44 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CUXwp-0005VV-Ns for qemu-devel@nongnu.org; Wed, 17 Nov 2004 17:06:43 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CUXwo-0005VR-WA for qemu-devel@nongnu.org; Wed, 17 Nov 2004 17:06:43 -0500 Received: from [38.113.3.61] (helo=smtp-out.hotpop.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CUXnV-0007Fe-6c for qemu-devel@nongnu.org; Wed, 17 Nov 2004 16:57:05 -0500 Received: from phreaker.net (kubrick.hotpop.com [38.113.3.103]) by smtp-out.hotpop.com (Postfix) with SMTP id C92FDA00A77 for ; Wed, 17 Nov 2004 21:56:54 +0000 (UTC) Received: from jbrown.mylinuxbox.org (pcp03144805pcs.midval01.tn.comcast.net [68.59.228.236]) by smtp-3.hotpop.com (Postfix) with ESMTP id 5421E11EA896 for ; Wed, 17 Nov 2004 21:56:50 +0000 (UTC) Date: Wed, 17 Nov 2004 16:56:36 -0500 From: "Jim C. Brown" Subject: Re: [Qemu-devel] qemu-img documentation Message-ID: <20041117215636.GA9859@jbrown.mylinuxbox.org> References: <41993485.6060704@bellard.org> <41e41e7a041115150417b7468d@mail.gmail.com> <41995BF4.7020102@bellard.org> <4199B04F.8020307@railnet.it> <419A1A03.9010707@brittainweb.org> <419A2000.1030706@mech.kuleuven.ac.be> <419B074D.6080700@railnet.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <419B074D.6080700@railnet.it> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Wed, Nov 17, 2004 at 09:09:49AM +0100, ML wrote: > Hdparm -g exits with a "Value too large for defined data type" message in > both cases. > This is a known problem with 32-bit linux programs in general ... to handle files larger than 2GB, the linux program must use fseeko(), ftello(), etc and then it must have been compiled with large file support. This problem doesn't exist on 64-bit archs where fseek(), ftell(), etc return 64bit integers. I have never used hdparm so I can't give any more info on it (tho I would expect that hdparm should have no problem with >2GB files as most actual hard disks are larger than this) but I have seen this problem with grep and file (my versions are quite old). -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection.