While you only open it for append, having two different open file
objects might well wreak havoc.
It is hard to see them writing NULs though. Overwriting each other
(maybe), interspersing message text etc etc, sure.
Each one would have a C stdio FILE * pointer (or similar, considering
Unicode and all) open underneath the Python layer. I’m not sure if
stdio will share FILE * pointers or not, but I wouldn’t count on it.
They’re independent. What a disaster it would be if they weren’t How
would you do stdio-mediated random access if they magicly hooked up?
That said, ISTR that Python 3 doesn’t use stdio beneath its file objects
any more, but it will be using something equivalent such as
file:///Users/cameron/var/doc/python/3.8.0/library/io.html#io.BufferedIOBase
With stdio, and almost certainly with BufferedIOBase (I have not
checked), a file opened for “append” will have the OS level file
descriptor opened with O_APPEND, which means that data are always
written to the end of the file, regardless of where the tell() pointer
is. That means that (a) files really do always append and (b) multiple
writers do not overwrite each other. But without care, the write buffers
may not be line-of-text aligned, so you can intersperse things and thus
make garbage.
So I do not expect files always opened in append mode to get spurious
NULs. I would suspect something else (eg a file not open in append mode
but faking it badly, for example, with a racy seek(),write() pair).
One thing I can ensure you is that stdio isn’t mysteriously writing NUL
bytes to your open file. It’s got to be something you are doing.
Or something someone else is doing
Try printing self.hrly_rpt.tell()
before each message written. If
your application is multi-threaded or multiple process, also print
os.getpid()
or threading.current_thread().ident
(as appropriate)
when you call tell()
.
Adding debug is always good. I like doing something like this sometimes:
write('['+line+']\n')
which concisely marks the start and end of each line. That would tell
you if the NULs were external, or part of the line data (outside vs
inside the square brackets).
Cheers,
Cameron Simpson cs@cskk.id.au