On Fri, Oct 28, 2016 at 10:59:42AM -0400, Theodore Ts'o wrote: > On Fri, Oct 28, 2016 at 10:04:12AM +0200, Oswald Buddenhagen wrote: > > > As for truncation, this might still happen if the file is not fsynced > > > explicitly at critical transaction points (including before fclose). > > > > > you're not getting truncation, but data corruption, as that's what > > appending a number of null bytes is. thers is _no_ standard that permits > > this without an interim system crash, fsync or not. > > Actually, without an fsync ***anything*** goes. In particular, if you > append to a file, and the system allocates a new block, it's fair game > for the file system to attach a block to the disk, but mark the block > the as uninitalized, so that reads to that block results in zeros.
Userspace process generally DO NOT read raw blocks from disk. It uses kernel's buffer space, so buffered data should be consistent regardless of disk contents. Oswald is right, process completion (by exit() or interrupt by signal) can only truncate data, but can not corrupt. Only system crash can lead to data corruption. -- Eugene Berdnikov ------------------------------------------------------------------------------ The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik _______________________________________________ isync-devel mailing list isync-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/isync-devel
