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 <manlio....@gmail.com <javascript:>> 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 CreateFile() of Win32 API?). > > > > 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. > > WriteFile does not follow these principles. > > Well, I definitely sympathize your line of reasoning, but it's not that > simple. For instance, a WriteFile() truncates the file when it exists. > A well-written application which wants to _replace_ a file must go this > route: > > > > [...]
> II. "Robust" approach: > > 0) Open the directory entry containing the file. > 1) Same as (1) above. > 2) fsync() the new file's contents. > 3) rename() the new file over the old one. > 4) fsync() the directory entry containing the file. > > Here, (4) is an oft-forgotten task, and it requires the openat() > / renameat() and other whateverat() functions, and the step (0). > > Thanks, but I'm well aware of this. I also wrote a package that implements an atomic storage atop a filesystem. I have not yet released it since the golang.org/x/sys is missing some syscalls I need. > Now here comes another consideration: certain file operations are > atomic on a scale larger than a single file. Consider a package > management program: when it unpacks a package, it makes little sense > making sure each file it unpacks is fdsync()-ed right after it was > written -- simple because it unpacking is terminated, it doesn't matter > whether the files extracted so far actually hit the underlying medium. > So we can unpack and then issue syncfs(2) all them all at once. > What I'm leading to, is that WriteFile() is just a narrowly-scoped > utility function. For advances cases you will almost inevitably > a) think your strategy through; b) write complex custom code. > > 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. 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.
