Do I need to os.fsync() before f.close()?
Question:
"what exactly the python’s file.flush() is doing?" says you should first f.flush() and then os.fsync(f.fileno()) to make sure the data are written to the disk.
Furthermore, "does close() imply flush() in Python?" claims that f.close() implies a flush().
Now, the question is: should I do
os.fsync(f.fileno())
f.close()
or, does f.close() also implies an os.fsync()?
Here are the doc of Python IO, the doc of Python file close, and the source code. A quick search of ‘fsync’ returned no relevant info.
Answers:
I have tried both os.fsync() then f.close() and os.fsync() only. Both will be giving the same result of immediate data written to the file. The file is updated using either methods despite a sudden power off occur at the main electrical outlet and power back on later.
So, f.close() is not necessary when there’s os.fsync().
I checked myself by stracing a test script and no it does not imply an fsync.
f.close() implies a f.flush() because it has to. f.flush() writes the internal
(user space) buffers to the associated file descriptor and you can not write to a file descriptor after closing it. However writing to the kernel buffers does not guarantee durability and this is where fsync comes into play.
"what exactly the python’s file.flush() is doing?" says you should first f.flush() and then os.fsync(f.fileno()) to make sure the data are written to the disk.
Furthermore, "does close() imply flush() in Python?" claims that f.close() implies a flush().
Now, the question is: should I do
os.fsync(f.fileno())
f.close()
or, does f.close() also implies an os.fsync()?
Here are the doc of Python IO, the doc of Python file close, and the source code. A quick search of ‘fsync’ returned no relevant info.
I have tried both os.fsync() then f.close() and os.fsync() only. Both will be giving the same result of immediate data written to the file. The file is updated using either methods despite a sudden power off occur at the main electrical outlet and power back on later.
So, f.close() is not necessary when there’s os.fsync().
I checked myself by stracing a test script and no it does not imply an fsync.
f.close() implies a f.flush() because it has to. f.flush() writes the internal
(user space) buffers to the associated file descriptor and you can not write to a file descriptor after closing it. However writing to the kernel buffers does not guarantee durability and this is where fsync comes into play.