On Mon, Jun 24, 2013 at 12:48:11AM -0400, [email protected] wrote: > > On Sat, Jun 22, 2013 at 02:20:18PM -0400, [email protected] wrote: > > > Looking at the .mbsyncstate files showed they were all filled with Nulls. > > > > > this is typically what a file system like xfs would do after a crash. > > I don't know enough about linux file systems to know if it's > significant, but my system uses ext4. > ext4 could still have the same problem (though i thought they made an effort to fix this particular rewrite+rename scenario. at least btrfs handles it gracefully).
> > > I have been using the git version of mbsync for a couple weeks (since > > > June 13). > > > > > hmpf. the above should not happen then - see the FSync option. > > I hadn't noticed the Fsync option. I'll add it to my config files. > it's "on" by default. > > anyway, there is no plausible way how mbsync itself could write a state > > file of all zeros (it's a text file written line wise). > > > > you should check your kernel log for anything unusual. > > Nothing unusual in the kernel log. I do run linux in a VMWare client > on a laptop, though. So perhaps there is something about that which > would cause problems. (just speculating) > well, that only means that both a host and guest system crash can mess up the guest file system. if you had no crash (possibly due to a suspend attempt going awry?), then this possibility is sort of irrelevant. if you are using a [delayed commit] virtual drive, a buggy implementation of that could cause the problem. but this is all speculation, too. you can use the undocumented debugging option -J to prevent that mbsync commits the state file and throws away its journal, but that is going to be slow at some point. you could use valgrind (or better gcc 4.8's address sanitizer) to see whether the observed effect results from a memory corruption (that's pretty much the only way the problem could be internal to mbsync). that's all irrelevant if the problem does not show up again to start with ... regards ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ isync-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/isync-devel
