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: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=
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:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:content-type; s=default; bh=0ftDTijvieHeC
	XUPOtSPTookytM=; b=kU67fSGERL6r7mY6XHfdxAjwFEbqXJ6K+4wCR/ezUUK8z
	IloiO0yYN8UmCXkDBf5iarfBpHXDxzBt+XdDCpVaUfFTEcY3A0PHJtBoDO/XFt7S
	gPOlBqBJo8+PL936wwsN8O7DrPA0i9Btst9WKLoOVv6W/x+AcBoLjhXm2O9CQg=
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.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=U*corinna-cygwin, corinna-cygwin AT cygwin DOT com, corinnacygwincygwincom, sk:corinna
X-HELO: mail-qt0-f175.google.com
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;        d=1e100.net; s=20161025;        h=x-gm-message-state:mime-version:in-reply-to:references:from:date         :message-id:subject:to;        bh=4Ac4XPt+1YksZVXWuriXu6VCvHzrZL71nACBN6v8+Io=;        b=P2NUBZ2JSvCa1iBHfScC25J47VL8u4nockrH3kFXfRkvF/cEofGfMC5gZlPajnHEGU         S+01DTdDmmrmksp2IiztzZxtgMalHiZYB9UE7uYtx1mbjhcsir2L3YZREzEPKFaO24na         COEkonAcBWXydSbOQjsWDVIQ3S/JA2BNwVaAV5z6lueridU29zv9wUA+j9OgUAPmeDVi         VsPPNiu9UZRo1vqXNZISfrmB94Fgi3YxPqE6o7xjIbS2k8+Wci8LfwIrQaPAqmjpEJeY         +1mSJFeGNPvwJEgeZxIajfuPO1AcRrWgXlt/UONPLYemlTXJulikGOuNq6NSeHVfTsBp         Id1A==
X-Gm-Message-State: AKGB3mKuaBGfYh1LDHkv108sEXRhV2S4UVpBDizJcg2m9wyX1Rxiy8sn	eUpYQQ0As0egz0WlSEjntXsejKlviSCR39kw34YCszu0
X-Google-Smtp-Source: ACJfBovpy/8EBoJuRHlrubLMAOlAmewNuacQKO0LkH1LLVsc+4779ja3RHWLlF97+k1d9sV8h9syShfEhF1LU9ZXkOI=
X-Received: by 10.200.46.50 with SMTP id r47mr5436213qta.314.1513698416526; Tue, 19 Dec 2017 07:46:56 -0800 (PST)
MIME-Version: 1.0
In-Reply-To: <20171219091431.GF11285@calimero.vinschen.de>
References: <20171218131035 DOT GB11285 AT calimero DOT vinschen DOT de> <5a385ced DOT 195b9d0a DOT d434 DOT 5400 AT mx DOT google DOT com> <20171219091431 DOT GF11285 AT calimero DOT vinschen DOT de>
From: Ivan Kozik <ivan AT ludios DOT 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 AT cygwin DOT com
Content-Type: text/plain; charset="UTF-8"
X-IsSubscribed: yes

On Tue, Dec 19, 2017 at 9:14 AM, Corinna Vinschen
<corinna-cygwin AT cygwin DOT 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