[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: fsfs rep on Win98SE lock file problem

From: Ben Reser <ben_at_reser.org>
Date: 2004-10-25 06:58:25 CEST

On Sun, Oct 24, 2004 at 12:24:50PM -0400, Greg Hudson wrote:
> Look up the documentation for LockFileEx(); you'll see there is a flag
> field for a shared vs. exclusive lock. The idea is that many people can
> get shared locks on the same file at the same time, but nobody can get
> an exclusive lock on the file until no one else has a lock of any sort.
>
> If win98 does not have LockFileEx(), then it sounds like APR silently
> maps shared locks (or "read locks") to exclusive locks, meaning a
> repository can only be opened once at a time, meaning any operation
> which opens a repository twice in the same process won't work. Since
> "checkout" is one of those operations (due to some sloppiness in
> libsvn_client), that renders svn not terribly useful.

Correct from file_io/win32/flock.c:

if (apr_os_level >= APR_WIN_NT) {
    /* Syntax is correct, len is passed for LengthLow and LengthHigh*/
    OVERLAPPED offset;
    memset (&offset, 0, sizeof(offset));
    if (!LockFileEx(thefile->filehand, flags, 0, len, len, &offset))
        return apr_get_os_error();
}
else {
    if (!LockFile(thefile->filehand, 0, 0, len, 0))
        return apr_get_os_error();
}

I really don't think this is worth trying to fix. Though I do agree
that the APR behavior is wrong. If you set flags that aren't supported
by the platform you should get APR_ENOTIMPL.

But in order for us to work around it would require us to implement our
own locking scheme. Don't think it's worth it for a dying platform that
we already didn't technically support and that is about to be end of
lifed anyway.

-- 
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 25 06:58:39 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.