I made a simple library for personal use awhile ago (
https://github.com/rboyer/safeio) that tries to sequence posix atomic
operations and fsync operations on file and directories for those times
when you just need:
1. create temp file
2. write to temp file
3. fsync and close temp file
On Fri, Jul 22, 2016 at 3:40 AM, Manlio Perillo
wrote:
>
> I think your reasoning is wrong.
> WriteFile is a "self contained" function; it does not return the handle to
> the file, so it can not be used inside a transaction.
> I really don't see valid reasons to not call Sync.
WriteFile is a conv
On Fri, Jul 22, 2016 at 12:40 PM Manlio Perillo
wrote:
> I really don't see valid reasons to not call Sync.
There are valid use cases where WriteFile produces a transitive file with
no requirements whatsoever to reach any storage above the kernel caches.
Performance in this cases would be [badly
Il giorno giovedì 21 luglio 2016 22:01:52 UTC+2, Konstantin Khomoutov ha
scritto:
>
> On Thu, 21 Jul 2016 21:17:38 +0200
> Manlio Perillo > wrote:
>
> > >> What is the reason why ioutil.WriteFile does not call File.Sync?
> > >
> > > I'd say that's because to inhibit this behaviour when needed
On Thu, 21 Jul 2016 21:17:38 +0200
Manlio Perillo wrote:
> >> What is the reason why ioutil.WriteFile does not call File.Sync?
> >
> > I'd say that's because to inhibit this behaviour when needed you'd
> > need to implement ioutil.WriteFileNoSync() or have an option flag
> > as an argument (remem
On Thu, Jul 21, 2016 at 2:17 PM, Manlio Perillo
wrote:
> On Thu, Jul 21, 2016 at 8:39 PM, Konstantin Khomoutov
> I'm curious to know why one wants to inhibit the durability behaviour.
> AFAIK, several design choices of Go and its standard library are
> designed to make program safe and robust.
> W
Il giorno giovedì 21 luglio 2016 21:28:09 UTC+2, Axel Wagner ha scritto:
>
> There are almost no use cases that require syncing the file. The operating
> system is designed with a good buffering layer for a reason. If you do have
> such need, it is trivial to write your own version of WriteFile t
There are almost no use cases that require syncing the file. The operating
system is designed with a good buffering layer for a reason. If you do have
such need, it is trivial to write your own version of WriteFile that does
this.
On Thu, Jul 21, 2016 at 9:17 PM, Manlio Perillo
wrote:
> On Thu,
On Thu, Jul 21, 2016 at 8:39 PM, Konstantin Khomoutov
wrote:
> On Thu, 21 Jul 2016 11:17:18 -0700 (PDT)
> Manlio Perillo wrote:
>
>> What is the reason why ioutil.WriteFile does not call File.Sync?
>
> I'd say that's because to inhibit this behaviour when needed you'd need
> to implement ioutil.W
On Thu, 21 Jul 2016 11:17:18 -0700 (PDT)
Manlio Perillo wrote:
> What is the reason why ioutil.WriteFile does not call File.Sync?
I'd say that's because to inhibit this behaviour when needed you'd need
to implement ioutil.WriteFileNoSync() or have an option flag as an
argument (remember CreateFi
I would say that syncing file contents is a more advanced operation
that stems from some knowledge about the persistence requirements of
your application. If you have those requirements you need to be in
control and should not use a convenience operations like WriteFile.
Also, performance.
(I've p
On Thu, Jul 21, 2016 at 8:17 PM Manlio Perillo
wrote:
> What is the reason why ioutil.WriteFile does not call File.Sync?
That would be harmful.
--
-j
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop re
What is the reason why ioutil.WriteFile does not call File.Sync?
Thanks
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...@googlegro
13 matches
Mail list logo
