>From the program's perspective the file is indeed flushed on close. The
kernel deferring writes to disk can only have any effect if the system
crashes, and the files will be flushed to disk within a short time anyway.
You absolutely do NOT need to call fsync every file on close unless you
require the data to be written to disk synchronously. In the vast majority
of cases you don't need that, and calling fsync takes a long time and makes
the system less efficient.

On Mon, Aug 27, 2018 at 3:09 AM Manlio Perillo <manlio.peri...@gmail.com>
wrote:

> No, the file is not flushed on close.
> https://linux.die.net/man/2/close
>
> "A successful close does not guarantee that the data has been successfully
> saved to disk, as the kernel defers writes. It is not common for a file
> system to flush the buffers when the stream is closed. If you need to be
> sure that the data is physically stored use fsync
> <https://linux.die.net/man/2/fsync>(2). (It will depend on the disk
> hardware at this point.)"
>
> You can just Sync the file, to make sure this not the problem.
>
>
> Manlio
>
> On Monday, August 27, 2018 at 10:19:37 AM UTC+2, Paweł Szczur wrote:
>>
>> If you're asking about dmesg, I'm not seeing anything related.
>> Yes, I'm on linux. The dir was created successfully, I guess it was not a
>> problem. Also, I believe the file is flushed on Close.
>>
>> I will look into the link.
>>
>> Paweł
>>
>> On Friday, August 24, 2018 at 6:33:15 PM UTC+2, Manlio Perillo wrote:
>>>
>>> On Friday, August 24, 2018 at 4:19:17 PM UTC+2, Paweł Szczur wrote:
>>>>
>>>> Thanks. Both things you mentioned are already fixed. The MakeDir may of
>>>> course fail and now I handle it, but in described situation it was not an
>>>> issue.
>>>> The files were written for most of the day successfully and suddenly
>>>> they stopped to appear.
>>>> The disk was and is not full. There was no error returned by any
>>>> function (I've examined logs).
>>>>
>>>
>>> Did you checked the system/kernel logs?
>>>
>>> If you still are unable to find the cause of the problem, and assuming
>>> you are on an UNIX system, you can try to change the code to make sure that
>>> both the new directory entry, and the new file data is flushed to disk.
>>> For the directory entry you have to open the directory with os.OpenFile,
>>> passing the os.O_RDONLY|unix.O_DIRECTORY flags, and call Sync after the new
>>> file is created.
>>>
>>> See http://danluu.com/file-consistency/
>>>
>>>
>>> Manlio
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to