subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tobias Bading <tbad...@web.de>
Subject Re: strange E/W200033 (b)locking error/warning when trying to modify a svn 1.8 working copy over SMB share
Date Thu, 03 Apr 2014 18:07:12 GMT
On 03.04.2014, at 19:46, Philip Martin wrote:
> Tobias Bading <tbading@web.de> writes:
> 
>> fcntl(3, F_SETLK, {type=F_RDLCK, whence=SEEK_SET, start=1073741824, len=1}) = 0
>> fcntl(3, F_SETLK, {type=F_RDLCK, whence=SEEK_SET, start=1073741826, len=510}) = 0
>> fcntl(3, F_SETLK, {type=F_UNLCK, whence=SEEK_SET, start=1073741824, len=1}) = 0
> 
> There should be a second fcntl with F_UNLCK, start=0, len=0 which
> unlocks the whole file.  On my Linux system it is present whether or not
> I use exclusive locking:
> 
> fcntl(3, F_SETLK, {type=F_RDLCK, whence=SEEK_SET, start=1073741824, len=1}) = 0
> fcntl(3, F_SETLK, {type=F_RDLCK, whence=SEEK_SET, start=1073741826, len=510}) = 0
> fcntl(3, F_SETLK, {type=F_UNLCK, whence=SEEK_SET, start=1073741824, len=1}) = 0
> fcntl(3, F_SETLK, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0}) = 0
> 
> 
>> access("/smb/<path-to-share>/<wc-root>/.svn/wc.db-journal", F_OK) = -1

>> ENOENT (No such file or directory)
>> fstat(3, {st_mode=S_IFREG|0600, st_size=100352, ...}) = 0
>> access("/smb/<path-to-share>/<wc-root>/.svn/wc.db-wal", F_OK) = -1 
>> ENOENT (No such file or directory)
>> fstat(3, {st_mode=S_IFREG|0600, st_size=100352, ...}) = 0
>> [...]
>> fcntl(3, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=1073741825, len=1}) = 0
>> [...]
>> fcntl(3, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=1073741824, len=1}) = 0
>> 
>> then 10 times
>> 
>> fcntl(3, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=1073741826, len=510}) = -1
EACCES (Permission denied)
> 
> The missing F_UNLCK means the file is still locked and so this fails.  I
> don't know why SQLite is missing the F_UNLCK.
> 
> -- 
> Philip Martin | Subversion Committer
> WANdisco // *Non-Stop Data*

Hi Philip,

I knew I should have appended the whole trace... :-(
Sorry for the confusion. The [...]s *do* include more locking related fcntl
calls, including unlocks. However, given that one process shouldn't be able
to lock itself out (if I read the man page correctly), I tried to reduce the
trace output to the parts I thought were most relevant.

I can post the whole trace tomorrow. I'll also try to reproduce the error
with a fresh working copy to make sure there's no stale lock held by an smbd
daemon messing things up.

Thanks,
Tobias


Mime
View raw message