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:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=UkZzBE4Gg+iN74k/Qf4Dr4Z8sefSRYDSWGnM4HyF2gZiCc0qRBiNi
	YO5ZWYH0gi/Sa21QGzJvVnIfOwgdfcGUFZE3GD1E48hAH9qGreT99qN3cxzTtcVG
	DuVI598/wRRsEbiFrgGrMWYf9heQTqIBiStN7FLre9logrz6qYvONo=
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:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	bh=WHqkrakYPIw3WujN5Zo0ciqAYfA=; b=HYZDDbaSEOURtftHsQkIdnHQQOIl
	F1DQXxnlPg0NSTHRwrGSep7VWkVo52fuBSsyV6HxKbvfuSZGNawStsWCrRoy1Sg5
	BPpQN14OqPzgHgKrCKZJrGwLor7WYCIby7Idnrgl64/e9GWBQCWjunIoCfBOkXtO
	guwAEircUmkp348=
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=-100.3 required=5.0 tests=AWL,BAYES_00,GOOD_FROM_CORINNA_CYGWIN,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_BRBL_LASTEXT,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=expectation
X-HELO:	drew.franken.de
Date:	Tue, 19 Dec 2017 10:14:31 +0100
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: Wrong file position after writing 65537 bytes to block device
Message-ID:	<20171219091431.GF11285@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<20171218131035 DOT GB11285 AT calimero DOT vinschen DOT de> <5a385ced DOT 195b9d0a DOT d434 DOT 5400 AT mx DOT google DOT com>
MIME-Version:	1.0
In-Reply-To:	<5a385ced.195b9d0a.d434.5400@mx.google.com>
User-Agent:	Mutt/1.9.1 (2017-09-22)

--C94crkcyjafcjHxo
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Dec 18 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 tell, =
you
> cant do that. quoting myself:
>=20
> > Seeking, reading and writing must all be done in multiples of sector si=
ze, 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"

Neither glibc nor FreeBSD show this behaviour.  Keep in mind that stdio
is designed for buffered I/O.  What should happen, basically, is that a
multiple of the stdio buffersize is written and the remainder is kept in
the stdio buffer:

  fwrite(65537)
  -> write(65536)
  -> store 1 byte in FILE._buf

ftell calls lseek which returns 65536.  It adds the number of bytes
still in the buffer, so it should return 65537.  Further fwrite's
seemlessly append to the bytes already written, as expected.  ftell
calling fflush and thus setting the current file position to the next
sector boundary breaks this expectation.

I pushed a patch yesterday and uploaded new developer snapshots to
https://cygwin.com/snapshots/

Please test.


Thanks,
Corinna

--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--C94crkcyjafcjHxo
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJaONh2AAoJEPU2Bp2uRE+gjpUQAIuLQ8+G0uN4Ha5Ky1kOTrjC
RVbEAUflICtbOGGukyK5zHFn0RZEXlcUv0q22m2D4buFZfve/+lQjmNe+ZexY9Tq
qdO7eg0FM4KOWp62zuSejzM+ZbBUC0lBmuq9i5X+2Y1/U3Q4iTm+moNbuEygLYTf
MqBANkvEtamTZghP+8UQnu4AOiJj8Dx6UyhWIdr6u6Yp79uvhe06M01SDJE3nVG8
R6uQQA4sjnYb8ARHwShM9319Cf5vy1S39ZcouWKNGG27LVtufDej8pwRlQgEZ37J
JQsY3YVWOgHt9QFhzhBLqhwAYHTaqW9aqQjz++rhzOBZQixBL8T/4eya+eYCHOKS
RM2wpr3e29+1OjJAqYrUoNvyNAmT5s1gH6CB5wE5CuCarTuofqAX7LDZ2LkW277q
eNrkfKRsn7tW3YH79/PO/dVOHU0CEuOTi6XGSZEHzpu9a65bKGLcxU9SdPh7UgPf
cCwTBRF8aVhYLhq535wWYmLBMgit/FRQqjmnFYAgOD2sljCAj1scnT75n9vOtDD/
aDC3Xfbn2aKjDYNnqfs7U+q0nVkJpYTFDOCdOAJXgncKvNH2j6cOXl07Qp5XC4s8
Jg+gTPryRrsEx2zw+82+xeRackIItOfZW5zIvt3ey72zc47iEwwTPnwL926jB8Rz
JaPfpjH8m+hTcLtsjWJ8
=5qkl
-----END PGP SIGNATURE-----

--C94crkcyjafcjHxo--

- Raw text -