2014-06-29 2:18 GMT+02:00 Andy Goth <andrew.m.g...@gmail.com>:
> I did a bisect to pinpoint the fault. This is Fossil, after all.
>
> $ f bisect status
> 2013-11-19 13:09:40 6791ad1185f374dc BAD CURRENT
> 2013-11-15 12:58:56 1928cf526ef478b4 GOOD
> $ f timeline 6791ad1185f374dc
> === 2013-11-19 ===
> 13:09:40 [6791ad1185] *CURRENT* Now that checkout_cmd() can handle the
> situation that vid==0 ([b725c1cf26]), no longer assume that the
> initial commit has rid=1: If the initial commit is not empty that
> will not be true any more. (user: jan.nijtmans tags: trunk)
> === 2013-11-15 ===
Reading all this (and triggered by the finding that my commit
might have introduced a bug.......) ;-)
My explanation is that [6791ad1185] really introduced the
bug, but not by really causing it but by unmasking a
bug which was already there. This commit changed
the way a repository is opened for the first time, so
it changes the order of I/O-operations done to the
drive. On most systems this makes no difference,
but apparently on VirtualBox shared drives it does.
Why? My guess is that it's the windows file system
which is at fault here: sometimes another process
can block I/O operations for a short while (e.g. McAfee
for checking whether there is a viris in it). SQLite
has a workaround for this problem (the retry mechanism
in os_win.c), but that's only for win32 not for UNIX.
My guess is that VirtualBox uses the same win32
blocking to do some internal work, but on the host
OS fossil is not prepared to handle that.
If my theory is true, then this problem only happens
when a UNIX version of fossil is running within
VirtualBox. The error occurred when syncing a
directory after a file in it was deleted.I think
this file was blocked by VirtualBox somehow.
Compiling fossil with -DSQLITE_DISABLE_DIRSYNC
might be just a good idea to fix this. Worth a try!
B.T.W.: Cygwin suffers from the same problem
when using the "unix" vfs, that's how my
theory started.
Regards,
Jan Nijtmans
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
