Read only file open on windows file share in a Python script locks a local write?

Question

I have an interesting issue I'm trying to solve, some background so you don't just say "why not do it this way instead?!". There's a PC running a commercial closed source scoreboard program, that I need to read data from for a program I'm writing in Python. The scoreboard software runs on a windows (10/11, not sure) desktop OS install. My software is written in Python, running on a windows 11 home laptop, inside PyCharm IDE while I develop it.

The scoreboard software outputs its on screen data to an XML file (or JSON, or a TCP or UDP connection, broadcasting UDP would be ideal!, but it's XML and I can't change it, it's how they run it and I don't have much influence).

I have a read-only share that I can connect to to read from that file. I'm using Python 3.12 and element tree to parse the XML. The file gets updated every time the scoreboard changes. Most of the time that's once a second, sometimes it's once every 10th of a second. I open the file for reading once every 0.5s – I'm trying to catch the clock it displays and not be noticeably out of sync with it. I'd like to read the file every 10th when it's updating every 10th too, but that makes the problem worse ... enough pre-amble. What seems to be happening is some sort of race condition. Occasionally during normal running (updates every second, I poll every 0.5s), the file locks up and my read of it returns the same file, no updates – it looks like the scoreboard software can't write to it so it gives up. As soon as the scoreboard flips to writing every 10th of a second instead of every second, I see the same file over and over (ie: it's not updating, something's given up), I don't see an error. This gives rise to a possible really ugly workaround (if it's not changed since last time, restart yourself or similar, urk ...)

I think what's happening, is that when I open it to read it, that read is blocking the scoreboard from writing to the file. I think this is an SMB/CIFS protocol thing, because when I use this on my test environment where my software and the scoreboard are running on the same box I cannot replicate the fault. That could just be timing though. Likewise my colleage who runs the scoreboard has his own script running on the scoreboard PC that also reads the XML file, and when it's run locally, it seems to work just fine, but when he tried to run it over a share, he would see the same problem. It is not an option for me to run software on the scoreboard PC, I have to access the XML file remotely using windows shares. Unless I knocked up some network thing on the scoreboard PC that stuck the XML on an HTTP server or something, but I really don't want to and I don't think they'd let me.

I don't care if one of my reads fails every now and then, it's wrapped in a "try/except" and will just skip a bad read if it happens, it's not that critical, I can lose a bit of data and it won't break anything. My read is : ` ET is eventtree The timing is coming from wxPython's event loop.

 try:
            if includes.OkToReadSBFile == True:
                with open(SBSourceFile) as SB_File:
                    mytree = ET.parse(SB_File)
                    includes.LastMyTree = mytree
                    SB_File.close()
            else:`

I'm being careful to close the file- I'm not sure if ET.parse() does it automagically or not?

I haven't tried running it outside of PyCharm (which may be doing something funky with file opens?).

Any clues? I don't understand why a read-only read would block a write. Is there something in windoze filesharing I could tweak to get it to behave or am I misunderstanding how windows file opening works and I'm only seeing the fault because network access is slower and thus I'm more likely to see the fault than my colleague's software (also Python, also using elementtree to parse the XML) because it's over the wire instead of local?

I've tried changing the timing of the open, but that just increases or decreases the odds of tripping the issue.