bpo-36807: When saving a file in IDLE, call flush and fsync

[gvanrossum]

This came up during today's final PyCon keynote -- IDLE was called out
as one of the two editors not to use when live-coding on Adafruit's
Circuit Playground Express (https://www.adafruit.com/product/3333).

I think that the problem referred to is that IDLE doesn't guarantee
that the bits are actually flushed to disk -- they may linger in the
OS filesystem cache. And I think this PR fixes the issue.

I've tested that this doesn't break things, but I don't have the right
cable around so I cannot test this with the hardware handed out to
PyCon attendees until Wednesday at the earliest.

https://bugs.python.org/issue36807

[gvanrossum]

@dhalbert Can you test this on Windows? Thanks for finding this issue in the first place!

[dhalbert]

I tested this fix by editing the 3.7.3 IDLE code by hand, and editing this test program as code.py on a CIRCUITPY drive on Windows 10:

import time
i = 0
while True:
    print(i)
    i += 1
    print("""\
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
""")
    time.sleep(1)

I typically test write flushing by editing a short program like this, and duplicating the print lines so that the size of the program grows by >512 bytes. This forces a rewrite of the FAT12 information because the program has increased in size by one or more filesystem blocks. Then I shrink it back down again. If file flushing doesn't happen immediately, the program will often throw a syntax error (because it's missing some blocks), or CircuitPython will get an I/O error, which is what happened before I patched IDLE.

So this looks good!

[gvanrossum]

@terryjreedy I personally think this is good to go in. The standard builtin open() always returns an object with flush() and fileno()methods, andos.fsync()` exists on Linux, Mac and Windows. I have no idea whether it would be safer to print a message (how and where?) or just ignore errors -- perhaps the right thing to do is just to let IDLE crash in the extremely rare case where a call does fail?

[terryjreedy]

I am most worried about an exception from pulling the usb plug, in which case ignoring it should be fine. I will merge this tomorrow with try:...except:pass added.

[gvanrossum]

I don't see why anything extra is needed. There's already a try/except OSError that puts up a dialog box. I just tried this on Mac (edit file, remove USB plug, try to save) and it worked as expected.

[bedevere-bot]

@terryjreedy: Please replace # with GH- in the commit message next time. Thanks!

[miss-islington]

Thanks @gvanrossum for the PR, and @terryjreedy for merging it 🌮🎉.. I'm working now to backport this PR to: 3.7.
🐍🍒⛏🤖

[miss-islington]

Thanks @gvanrossum for the PR, and @terryjreedy for merging it 🌮🎉.. I'm working now to backport this PR to: 3.7.
🐍🍒⛏🤖

[bedevere-bot]

GH-13280 is a backport of this pull request to the 3.7 branch.

[gvanrossum]

OK, I'll send a fix for the NEW typo.

[gvanrossum]

Typo fix is here: #13284

[miss-islington]

Thanks @gvanrossum for the PR, and @terryjreedy for merging it 🌮🎉.. I'm working now to backport this PR to: 3.7.
🐍🍒⛏🤖

[bedevere-bot]

GH-13288 is a backport of this pull request to the 3.7 branch.