X-Recipient:	archive-cygwin AT delorie DOT com
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=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; 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; s=default; bh=icLsh8Wls/pNaAubQ1LR9odbH/c=; b=kpWUQ
	zGeVb4MU4KMkOPn2Y0R/mOIlYvfjNBOGpf19GjD2oyq25Fi05AordxSIb12qSiIX
	jcy3qUtNtBnsMJhhJfmjBLUu+Db0rFZIL40FCjkN+pTINqLzSmrtsCmlKSt5vZtq
	MPucNVpiQA0vVAfKYRRjPFOa3V27fIMRYMmrS8=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
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
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
To:	Cygwin <cygwin AT cygwin DOT com>
Subject:	Re: Wrong file position after writing 65537 bytes to block device
X-PHP-Originating-Script:	501:rcmail.php
MIME-Version:	1.0
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>
X-Sender:	920-082-4242 AT kylheku DOT com
User-Agent:	Roundcube Webmail/0.9.2
X-CMAE-Envelope:	MS4wfMArmp9t508Yzj/0w+SuXFLjV8dui3VAuuPs+Y1LFLZ9w8vLSHikA4hav+pTIYbECRPjIEHfiRebOfoTcqiLAPLcfaKwnc31twbg7cvbxmO7HLu8afdY hQwzmnnfVaA+Oh8Yn2urLEQmhkLCmcs3oiCuG6cttq5W7I1xsOfgmKk7
X-IsSubscribed:	yes
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id vBKNXZ0W024828

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

- Raw text -