Re: [fossil-users] Problem accessing shared folder in VirtualBox

2014-06-29 Thread Jan Nijtmans
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


Re: [fossil-users] Problem accessing shared folder in VirtualBox

2014-06-28 Thread HeadshotX
--- Original Message ---
 On 6/27/2014 5:56 PM, Alexander Strobel wrote:
 Problem: I am getting the following error message when I try to
 open a repo wich lies in a shared folder of Oracles VirtualBox: 
 [somelocaldir]$ fossil open ../geelaunch.fossil SQLITE_IOERR:
 os_unix.c:29821: (22) 
 fsync(/media/sf_Projects/geelaunch_working/../geelaunch.fossil-mjC43B7293F)
 - Invalid argument fossil: disk I/O error: {COMMIT}
 
 Can someone confirm this behavior?
 
 I have similar problems with VirtualBox shared files, and they're not
 just with Fossil.  Don't use it VirtualBox shared files for Fossil.
 Instead use http or ssh to synchronize between a file outside and
 inside the virtual machine using VirtualBox's TCP/IP capabilities.

Thanks for the hint. I tried and got it to work this way.
Is there any chance that it will work like I tried it first? It is
working with http access, but there are so many steps to do before,
while and after and so it feels uncomfortable compared to a pure file
based solution... :)

Anyhow: Great piece of software. Especially the ticketing system and
everything without installation. Perfect! :)

Greets
al
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


Re: [fossil-users] Problem accessing shared folder in VirtualBox

2014-06-28 Thread HeadshotX
--- Original Message ---
 Is there any chance that it will work like I tried it first?
 
 SQLite is quite strict with the filesystem, and it needs it to work as
 advertised, for example with syncing and file locking.  VirtualBox is
 just not there yet.  Go bug them.  Give them a tiny test case, a
 sequence of commands to create a repository and try to open it.

Thank you for the detailed steps, I will write them to the VirtualBox team.

Just one last uncomfortable(?) question: Why does everything work as
expected in version 1.21 of fossil? (As long as I use fossil v1.21 it
works, but as i use v1.27 or higher it gives me the initial mentioned
error.)
Or more specifically: What changed in the sqlite3.c file that causes
this error?
I think this is a question that a competent supporter from the
VirtualBox team would ask me and I would like to have a good answer for
this case.
(Regrettably I am not able to compile the fossil code by myself. *c/c++
noob*)

Greets
al
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users