DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:content-type; q=dns; s=default; b=u59JsZ6
	hJHjxy+LM24GRDtRlAC/dK7JrcKiwjBSuSr1m+AzPa//MTjGKIOe69/TCHeHIa+f
	Cv34IKd7e/i8rTgtaWnX/ohxLDJ92BX5qMtds6RNmW1+UFjOGIZxJluyG5MPUMFs
	vvV6DFYvqE/Wca/4Qt4yeskPME7fBhryLcCQ=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
MIME-Version: 1.0
In-Reply-To: <20171219091431.GF11285@calimero.vinschen.de>
References: <20171218131035.GB11285@calimero.vinschen.de> <5a385ced.195b9d0a.d434.5400@mx.google.com> <20171219091431.GF11285@calimero.vinschen.de>
From: Ivan Kozik <ivan@ludios.org>
Date: Tue, 19 Dec 2017 15:46:24 +0000
Message-ID: <CAKyntiLyTBGcAx3iwhq7dX0wqiE3S685kwmhMg+U2A3huXVzUQ@mail.gmail.com>
Subject: Re: Wrong file position after writing 65537 bytes to block device
To: cygwin@cygwin.com
Content-Type: text/plain; charset="UTF-8"

On Tue, Dec 19, 2017 at 9:14 AM, Corinna Vinschen
<corinna-cygwin@cygwin.com> wrote:
> 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, 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 <stdio.h>

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));
    return 0;
}

cygwin reports 66048, while Linux reports 65537.  In cygwin, if such a
write is done in a loop, for example, you can get garbled output on
disk.

fflush can be visibly unnecessary when done from C, but python3 (where
I originally observed the problem) appears to do implicit flushing.

If this is annoying to fix and I am the only one who notices, please
don't worry about it, I can just write in proper block sizes to block
devices.

Best regards,

Ivan

--
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