Token file sometimes malformed

[DerGenaue]

I have a weird issue on one system where the token file is always malformed after login:

For some reason, it appends the last 4 chars of the last line in another new line:

<uname>
<token>
<time>
<token>
<time>
https://db5-client-s.gateway.messenger.live.com/v1
m/v1

This then results in the token file being unusable for the next start.
This only happens on one system (Debian 8, python 3.4, manually installed from repo).
It did not appear to happen, when SkPy is started with a correct token file.
It also isn't a new error; just one that can be avoided rather easily so I never really bothered.

Is this something known in any way?
The "w"-mode when writing that file should truncate it; could this nevertheless be a weird remainder in a buffer or something..? Any idea on how this could happen?
Do you think it might be worth it to just ignore excess lines when parsing the token file? (currently, excess lines fail parsing)

[Terrance]

Looks like this is specific to use of os.open():

>>> with open("test.txt", "w") as f:
...     f.write("11111111\n")
... 
>>> with open("test.txt", "w") as f:
...     f.write("2222\n")
... 
>>> with os.fdopen(os.open("test-fd.txt", os.O_WRONLY | os.O_CREAT, 0o600), "w") as f:
...     f.write("11111111\n")
... 
>>> with os.fdopen(os.open("test-fd.txt", os.O_WRONLY | os.O_CREAT, 0o600), "w") as f:
...     f.write("2222\n")
...

$ cat test.txt
2222
$ cat test-fd.txt
2222
111

Adding a call to f.truncate() before writing seems to cover it.

[DerGenaue]

Oh nice; you were able to reproduce it..
I was searching for the bug in the code...
Is it specific to any of the versions?

[Terrance]

https://github.com/OllieTerrance/SkPy/blob/418b1f59d741527664105f31f2c603f538a2af6c/skpy/conn.py#L309-L322

It's been there since the beginning, so has most likely always been like this, though curiously I haven't come across it before.

[DerGenaue]

I meant python versions 😂
my mistake

[Terrance]

Well it happens on 3.6 and 2.7, so plausibly all versions. In any case, should be handled now.

[DerGenaue]

BTW... I think the reason might be that you "forgot" the os.O_TRUNC flag..?

[Terrance]

Huh, yup, that'd do it too...