fsfs rep on Win98SE lock file problem

[John J Smith <jo...@rediffmail.com>]

Hello,

I was happy to learn (from the svn FAQ) that the
fsfs backend would support repositories on Win98.
I want to create repositories on Win98SE for
local, personal use (not for running a server).

However, both the svn 1.1.0 client (binaries from
the svn site; tried both the .zip and the .exe)
and TortoiseSVN 1.1.0 (build 1769) give a problem.
The fsfs repository creation goes okay.  But the
first checkout after that gives a `shared lock'
problem on db.lock.

Here is a transcript of the problem:

----------------------------------------------------------------------

C:\tmp > svnadmin --version
svnadmin, version 1.1.0 (r11180)
   compiled Oct  4 2004, 21:11:18

Copyright (C) 2000-2004 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).


C:\tmp > svn --version
svn, version 1.1.0 (r11180)
   compiled Oct  4 2004, 21:11:18

Copyright (C) 2000-2004 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).

The following repository access (RA) modules are available:

* ra_dav : Module for accessing a repository via WebDAV (DeltaV) protocol.
  - handles 'http' schema
  - handles 'https' schema
* ra_local : Module for accessing a repository on local disk.
  - handles 'file' schema
* ra_svn : Module for accessing a repository using the svn network protocol.
  - handles 'svn' schema


C:\tmp > svnadmin create --fs-type=fsfs root

C:\tmp > mkdir work

C:\tmp > cd work

C:\tmp\work > svn co file:///c:/tmp/root
svn: Unable to open an ra_local session to URL
svn: Unable to open repository 'file:///c:/tmp/root'
svn: Can't get shared lock on file 'c:/tmp/root/locks/db.lock': The process cann
ot access the file because  another process has locked a portion of the file.

C:\tmp\work >

----------------------------------------------------------------------

Analysis of the TortoiseSVN equivalent of the
above using a system call tracer seemed to
indicate that the db.lock file was being opened,
LockFile()d, opened again, and LockFile()d again
without releasing the first lock.

Is it a bug or a problem with my system?

Thanks,

jjs