Re: [Monotone-devel] Re: cygwin buildbot [Was: 0.27 cygwin compile error]

[Nuno Lucas]

On 7/16/06, Lapo Luchini <address@hidden> wrote:
> I was thinking about changing my "quick & dirty" change (i.e. using
> "C:\cygwin\tmp" as a temporary instead of "C:\Windows", which
> defintely seems a BAD default IMHO) to maybe use $TMP or $TEMP.
> But no, I guess that must be a system-wide setting, not a user-wide
> one, else different users won't see each other's locks, I guess.
> Hmm.
> The right thing to do would definitely be to fix "sqlite & cygwin &
> fcntl" issue.

SQLite locking is made on the database file (via LockFile with windows
and fcntl locks on unix, as can be seen on the os_*.c files). Special
platforms use different methods, like shared memory, when the file
system doesn't implement locking (the case of Windows CE).

It can open/create other files: journal files in the same directory as
the database file (they will be used to rollback the database if a
crash happens before the commit, so need to be in the same directory
when the database is open next) and temporary files (which are usualy
automatically deleted on close), located on the default system
directory for temporary files or the one set in the variable.

I don't think "c:\windows" is the default for the temporary files on
windows, but maybe that is a cygwin port thing  (which probably needs
more "care"). It seems wrong on all accounts, though, so I would make
sure the file is not created by another part of the program, and not
sqlite.

I remember from the old postgres cygwin port that the only way to have
unix style locks to work (reliable) is by having a cygwin lock daemon
running, so maybe it's what you need. Try googling for it in relation
to postgres.

I would not be surprised if that file it is trying to open on the
windows directory is one used by the cygwin locking daemon, which
isn't running, so fails.


Hope this helps.

Regards,
~Nuno Lucas