DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:to:subject:mime-version:content-type
	:content-transfer-encoding:date:from:in-reply-to:references
	:message-id; q=dns; s=default; b=MURFtFw0FuDO13eLxnIwal0d9eM0F6m
	REFPrdndh6qFklWa6cJI5AzophFWoMlMc2uQlhjlSkMbRoMvMaRkRY90V7gtzo34
	eqRmy8l+Es17ekxEqcU/4AQ+7F81vTcToR5eOkDpgAAaFcgGnoaiNVGEEnnko/Vh
	Prm6LvwtimsE=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
To: Cygwin <cygwin AT cygwin DOT com>
Subject: Re: Wrong file position after writing 65537 bytes to block device
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Date: Wed, 20 Dec 2017 15:33:15 -0800
From: Kaz Kylheku <920-082-4242 AT kylheku DOT com>
In-Reply-To: <5a385ced.195b9d0a.d434.5400@mx.google.com>
References: <20171218131035 DOT GB11285 AT calimero DOT vinschen DOT de> <5a385ced DOT 195b9d0a DOT d434 DOT 5400 AT mx DOT google DOT com>
Message-ID: <09b879460396d2d1912fb3dc086ee6db@mail.kylheku.com>
User-Agent: Roundcube Webmail/0.9.2
Content-Transfer-Encoding: 8bit

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.
>> 
>> Looks like a patch is required.  Stay tuned.
> 
> is it though? he says "write 65536 + 1 bytes", but as far as i can 
> tell, you
> cant do that. quoting myself:
> 
>> Seeking, reading and writing must all be done in multiples of sector 
>> size, in
>> my case 512 bytes
> 
> http://web.archive.org/web/stackoverflow.com/questions/37228874/how-to-fwrite-to-removable-volume
> 
> 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=/dev/zero of=/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