On 03.04.2014, at 19:46, Philip Martin wrote:
> Tobias Bading <tbad...@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
