On Jan 5, 1:08 pm, Nobody <nob...@nowhere.com> wrote: > On Mon, 04 Jan 2010 08:09:56 -0800, Brian D wrote: > > If I'm running a process in a loop that runs for a long time, I > > occasionally would like to look at a log to see how it's going. > > > I know about the logging module, and may yet decide to use that. > > > Still, I'm troubled by howfsync() doesn't seem to work as advertised: > > >http://docs.python.org/library/os.html > > > "If you’re starting with a Python file object f, first do f.flush(), > > and then do os.fsync(f.fileno())" > > The .flush() method (and the C fflush() function) causes the > contents of application buffers to be sent to the OS, which basically > copies the data into the OS-level buffers. > > fsync() causes the OS-level buffers to be written to the physical drive. > > File operations normally use the OS-level buffers; e.g. if one process > write()s to a file and another process read()s it, the latter will see > what the former has written regardless of whether the data has been > written to the drive. > > The main reason for usingfsync() is to prevent important data from being > lost in the event of an unexpected reboot or power-cycle (an expected > reboot via the "shutdown" or "halt" commands will flush all OS-level > buffers to the drive first). Other than that,fsync() is almost invisible > (I say "almost", as there are mechanisms to bypass the OS-level buffers, > e.g. the O_DIRECT open() flag).
An excellent explanation of the process. I've seen this in other programming environments, so I could visualize something to that effect, but couldn't have verbalized it. I certainly have a better idea what's happening. Thanks for the contribution. -- http://mail.python.org/mailman/listinfo/python-list