From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 39626 invoked by alias); 19 Dec 2017 16:13:25 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 39561 invoked by uid 89); 19 Dec 2017 16:13:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=principal, caveat, H*M:10af X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 19 Dec 2017 16:13:20 +0000 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id EC177356EC for ; Tue, 19 Dec 2017 16:13:18 +0000 (UTC) Received: from [10.10.125.48] (ovpn-125-48.rdu2.redhat.com [10.10.125.48]) by smtp.corp.redhat.com (Postfix) with ESMTP id A52EE19649 for ; Tue, 19 Dec 2017 16:13:18 +0000 (UTC) Subject: Re: Wrong file position after writing 65537 bytes to block device To: cygwin@cygwin.com References: <20171218131035.GB11285@calimero.vinschen.de> <5a385ced.195b9d0a.d434.5400@mx.google.com> <20171219091431.GF11285@calimero.vinschen.de> From: Eric Blake Message-ID: <9f29d418-10af-1dc7-2636-89cae1eb16f4@redhat.com> Date: Tue, 19 Dec 2017 17:43:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-12/txt/msg00198.txt.bz2 On 12/19/2017 09:46 AM, Ivan Kozik wrote: > Thanks, I can confirm that the 2017-12-18 snapshot fixed the test > program I posted. > > What about the harder case where the program calls fflush, though? > > #include > > int main(int argc, char *argv[]) { > FILE *f = fopen(argv[1], "w"); > char x[65536 + 1]; > fwrite(x, 1, 65536 + 1, f); > fflush(f); > printf("%ld", ftell(f)); Can block devices report an unaligned offset to lseek()? If not, then when writing an unaligned value to a block device, don't we have to do a read-modify-write of the larger aligned cluster, and then put lseek() back to the unaligned boundary, and have extra magic in ftell() to track that we are at an unaligned position within the block device? But that sounds like a lot of nasty overhead; and that it would be better to make sure that block devices can report unaligned lseek() locations (caveat: I haven't tested what Linux does in that regards). -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple