On 2016-12-07 07:30, Marko Rauhamaa wrote: > Tim Chase <python.l...@tim.thechases.com>: > > On 2016-12-07 00:29, Marko Rauhamaa wrote: > >> A word a warning: your code doesn't lock /var/run/utmp before > >> access, which is a race condition. The file may be updated at any > >> time, and ordinary file reads may yield corrupted records. > > > > Since the code is reading in record-sized blocks and never > > writing, I'm not sure how much possibility there is for a race > > condition. At worst, I imagine that it would result in reading > > the old data which isn't a horrible condition. > > If you read a full record at an offset, you might be right. However, > your code uses Python's buffered I/O: > > with open(utmp_fname, "rb") as f: > while True: > bytes = f.read(XTMP_STRUCT_SIZE) > > instead of os.open() and os.read().
Interesting. I read up on os.open() and os.read() https://docs.python.org/2/library/os.html#os.read but didn't notice anything there clarifying that it was unbuffered compared to the __builtins__.open() and fp.read() functions. Could you point me to resources where I can learn more about the distinctions? > > For under a certain block-size (PIPE_BUF, which I think used to be > > the minimum POSIX requirement of 512b, but is now 4096b on Linux), > > *nix operating systems were atomic in their reading and writing. > > That particular guarantee is true for pipes and FIFOs only. Ah, my error in misreading that as globally applicable. Thanks for ensuring accuracy. -tkc -- https://mail.python.org/mailman/listinfo/python-list
