From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 33855 invoked by alias); 20 Dec 2017 23:33:22 -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 32963 invoked by uid 89); 20 Dec 2017 23:33:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,FROM_STARTS_WITH_NUMS,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=sectors, H*r:4.72, transfer, Hx-spam-relays-external:ESMTPA X-HELO: smtp-out-no.shaw.ca Received: from smtp-out-no.shaw.ca (HELO smtp-out-no.shaw.ca) (64.59.134.9) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 20 Dec 2017 23:33:19 +0000 Received: from kylheku.com ([70.79.163.252]) by shaw.ca with ESMTPA id RnrPecHWWYy1iRnrRekBuR; Wed, 20 Dec 2017 16:33:17 -0700 X-Authority-Analysis: v=2.2 cv=f8g4PK6M c=1 sm=1 tr=0 a=95A0EdhkF1LMGt25d7h1IQ==:117 a=95A0EdhkF1LMGt25d7h1IQ==:17 a=IkcTkHD0fZMA:10 a=SMorJkV_YP8A:10 a=ocR9PWop10UA:10 a=9acuybUuAAAA:20 a=uPZiAMpXAAAA:8 a=NdF19oMqvYFINTQ3OPoA:9 a=QEXdDO2ut3YA:10 Received: from www-data by kylheku.com with local (Exim 4.72) (envelope-from <920-082-4242@kylheku.com>) id 1eRnrP-0002LW-Qr for cygwin@cygwin.com; Wed, 20 Dec 2017 15:33:15 -0800 To: Cygwin Subject: Re: Wrong file position after writing 65537 bytes to block device X-PHP-Originating-Script: 501:rcmail.php MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Dec 2017 23:59:00 -0000 From: Kaz Kylheku <920-082-4242@kylheku.com> In-Reply-To: <5a385ced.195b9d0a.d434.5400@mx.google.com> References: <20171218131035.GB11285@calimero.vinschen.de> <5a385ced.195b9d0a.d434.5400@mx.google.com> Message-ID: <09b879460396d2d1912fb3dc086ee6db@mail.kylheku.com> X-Sender: 920-082-4242@kylheku.com User-Agent: Roundcube Webmail/0.9.2 X-CMAE-Envelope: MS4wfMArmp9t508Yzj/0w+SuXFLjV8dui3VAuuPs+Y1LFLZ9w8vLSHikA4hav+pTIYbECRPjIEHfiRebOfoTcqiLAPLcfaKwnc31twbg7cvbxmO7HLu8afdY hQwzmnnfVaA+Oh8Yn2urLEQmhkLCmcs3oiCuG6cttq5W7I1xsOfgmKk7 X-IsSubscribed: yes X-SW-Source: 2017-12/txt/msg00237.txt.bz2 On 18.12.2017 16:27, Steven Penny wrote: > On Mon, 18 Dec 2017 14:10:35, Corinna Vinschen wrote: >> In general, the writes on disk devices is sector-oriented. Howewver, >> in this case ftell should have returned 65536. The problem here is >> that the newlib implmentation of ftell/ftello performs an fflush >> when called on a write stream since about 2008 to adjust for appending >> streams. Given your example (thanks for the testcase!) this seems >> pretty wrong. Looking further it turns out that neither glibc nor BSD >> actually calls fflush in this case. There's only a special case for >> appending streams, but this calls lseek, not fflush. >>=20 >> Looks like a patch is required. Stay tuned. >=20 > is it though? he says "write 65536 + 1 bytes", but as far as i can=20 > tell, you > cant do that. quoting myself: >=20 >> Seeking, reading and writing must all be done in multiples of sector=20 >> size, in >> my case 512 bytes >=20 > http://web.archive.org/web/stackoverflow.com/questions/37228874/how-to-fw= rite-to-removable-volume >=20 > so it would make sense that the position becomes "65536 + 512" You can do that on a "block" device. It's "raw" devices that have transfer unit restrictions. A block device creates an abstraction over a disk, dividing it into blocks. Those blocks are not related to the underlying sector size; they could be larger (e.g. 4096 byte block size, versus 512 byte sectors) or even smaller (e.g. 4096 byte block size, versus 65536 byte flash erase block size). Unix block devices let you read, write and seek using byte offsets and sizes. The bytes which are affected by a write operation map to one or more ranges in one or more blocks. All of the blocks have to be read into memory (if they aren't already). The bytes are updated, and then the blocks are marked dirty and written out (eventually). More changes can take place before that happens. So for instance if we have a block device (4096 bytes) over a flash device with 64 kB erase blocks, we can write just one byte somewhere in a block. When this change is flushed, the entire erase block has to be erased and rewritten. Because of the abstract nature of block devices, it's largely pointless to use the "dd" utility; you can use "cp" to copy them. "dd" is required when you need to control the exact size of the read and write calls. Thus "cat /dev/zero > /dev/blockdevice" has the same effect as "dd if=3D/dev/zero of=3D/dev/blockdevice". -- 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