explicitly sync file written by ioutil.WriteFile

353 views
Skip to first unread message

Awaken

unread,
Nov 17, 2011, 11:21:36 PM11/17/11
to golang-nuts
Hi, ioutil.WriteFile is really convenient. But I found that it will
not automatically sync the file to disk.
I know the performance consideration of this. But, why not provide
another method in the package called WriteFileAndSync?

Brad Fitzpatrick

unread,
Nov 17, 2011, 11:24:30 PM11/17/11
to Awaken, golang-nuts
And if the next line of your program is Foo(), should the ioutil package also provide WriteFileAndSyncAndFoo?

Where do you draw the line?

andrey mirtchovski

unread,
Nov 17, 2011, 11:26:15 PM11/17/11
to Brad Fitzpatrick, Awaken, golang-nuts
> Where do you draw the line?

WriteFileAndSyncAndFooAndDrawLine(), surely.

Awaken

unread,
Nov 17, 2011, 11:27:45 PM11/17/11
to golang-nuts
To Brad,
You didn't get me.
The problem is that there is no way to explicitly sync the file
written by ioutil.WriteFile unless one gets the handler of the file
again.

Another way around this is let ioutil.WriteFile to return a *os.File
as well.

On Nov 17, 10:24 pm, Brad Fitzpatrick <bradf...@golang.org> wrote:

Awaken

unread,
Nov 17, 2011, 11:28:06 PM11/17/11
to golang-nuts
kidding~

Russ Cox

unread,
Nov 18, 2011, 12:00:07 AM11/18/11
to Awaken, golang-nuts
On Thu, Nov 17, 2011 at 23:27, Awaken <awak...@gmail.com> wrote:
> Another way around this is let ioutil.WriteFile to return a *os.File
> as well.

Another way around this is to run godoc -src io/ioutil WriteFile,
copy that into your program, and adapt to suit.

L Campbell

unread,
Nov 18, 2011, 6:35:07 PM11/18/11
to golang-nuts
On Nov 17, 10:27 pm, Awaken <awake...@gmail.com> wrote:
> To Brad,
> You didn't get me.
> The problem is that there is no way to explicitly sync the file
> written by ioutil.WriteFile unless one gets the handler of the file
> again.
>
> Another way around this is let ioutil.WriteFile to return a *os.File
> as well.

The problem with having it return the file descriptor (or *os.File) is
that os.File.Close destroys the underlying file descriptor. For it to
return the value, it would have to defer responsibility for closing
the file to the calling code -- something that seems nonsensical to
me.
Reply all
Reply to author
Forward
0 new messages