aapost wrote at 2023-3-5 09:35 -0500:
> ...
>If a file is still open, even if all the operations on the file have
>ceased for a time, the tail of the written operation data does not get
>flushed to the file until close is issued and the file closes cleanly.
This is normal: the buffer is flushed
On 3/5/23 19:02, Cameron Simpson wrote:
On 05Mar2023 10:38, aapost wrote:
Additionally (not sure if this still applies):
flush() does not necessarily write the file’s data to disk. Use
flush() followed by os.fsync() to ensure this behavior.
Yes. You almost _never_ need or want this
On 3/5/23 09:35, aapost wrote:
I have run in to this a few times and finally reproduced it. Whether it
is as expected I am not sure since it is slightly on the user, but I can
think of scenarios where this would be undesirable behavior.. This
occurs on 3.11.1 and 3.11.2 using debian 12
ge(5000):
print(i,file=f)
From: Python-list on
behalf of aapost
Date: Sunday, March 5, 2023 at 6:33 PM
To: python-list@python.org
Subject: Bug 3.11.x behavioral, open file buffers not flushed til file closed.
*** Attention: This is an external email. Use caution responding, opening
attachments or c
> On 6 Mar 2023, at 01:42, Greg Ewing via Python-list
> wrote:
>
> On 6/03/23 1:02 pm, Cameron Simpson wrote:
>> Also, fsync() need not expedite the data getting to disc. It is equally
>> valid that it just blocks your programme _until_ the data have gone to disc.
>
> Or until it *thinks*
On Mon, 6 Mar 2023 at 12:41, Greg Ewing via Python-list
wrote:
>
> On 6/03/23 1:02 pm, Cameron Simpson wrote:
> > Also, fsync() need not expedite the data getting to disc. It is equally
> > valid that it just blocks your programme _until_ the data have gone to
> > disc.
>
> Or until it *thinks*
On 6/03/23 1:02 pm, Cameron Simpson wrote:
Also, fsync() need not expedite the data getting to disc. It is equally
valid that it just blocks your programme _until_ the data have gone to
disc.
Or until it *thinks* the data has gone to the disk. Some drives
do buffering of their own, which may
On 05Mar2023 10:38, aapost wrote:
Additionally (not sure if this still applies):
flush() does not necessarily write the file’s data to disk. Use flush()
followed by os.fsync() to ensure this behavior.
Yes. You almost _never_ need or want this behaviour. A database tends to
fsync at the end
On 3/5/23, aapost wrote:
>
> If a file is still open, even if all the operations on the file have
> ceased for a time, the tail of the written operation data does not get
> flushed to the file until close is issued and the file closes cleanly.
This is normal behavior for buffered file I/O.
On 05Mar2023 09:35, aapost wrote:
I have run in to this a few times and finally reproduced it. Whether
it is as expected I am not sure since it is slightly on the user, but
I can think of scenarios where this would be undesirable behavior..
This occurs on 3.11.1 and 3.11.2 using debian 12
Am 05.03.23 um 15:35 schrieb aapost:
I have run in to this a few times and finally reproduced it. Whether it
is as expected I am not sure since it is slightly on the user, but I can
think of scenarios where this would be undesirable behavior.. This
occurs on 3.11.1 and 3.11.2 using debian 12
On 3/5/23 09:35, aapost wrote:
Guess it could just be an annoying gotcha thing on me.
calling at least
f.flush()
in any cases where an explicit close is delayed would be the solution.
Additionally (not sure if this still applies):
flush() does not necessarily write the file’s data to
I have run in to this a few times and finally reproduced it. Whether it
is as expected I am not sure since it is slightly on the user, but I can
think of scenarios where this would be undesirable behavior.. This
occurs on 3.11.1 and 3.11.2 using debian 12 testing, in case the
reasoning lingers
13 matches
Mail list logo
