Comment 23 for bug 291565

Doh, I first tested with a NFS mount, but those work fine.
With smbmount I see "couldn't lock local file" indeed, for a readonly mount
(this is because smbmount doesn't adjust permissions like nfsmount does, for a readonly mount, so the permissions seem to indicate that the directory is writable, while it is not). Ah, with a readwrite mount I finally get the bug.
WARNING: Problem deleting stale lockfile /<path>/.directory.lock
WARNING: Problem deleting stale lockfile /<path>/.directory.lock
etc. forever. Definitely a KLockFile bug. Investigation showed:

lockFile() always returns LockFail, even though it creates the lock file fine.

173 if (st_buf != st_buf2 || S_ISLNK(st_buf.st_mode) || S_ISLNK(st_buf2.st_mode))
174 {
175 // SMBFS supports hardlinks by copying the file, as a result the above test will always fail
176 if ((st_buf.st_nlink == 1) && (st_buf2.st_nlink == 1) && (st_buf.st_ino != st_buf2.st_ino))
177 {
[...]
181 }
182 return KLockFile::LockFail;

The first if() is indeed always false, but the second one too:
st_buf.st_nlink is 2, st_buf2.st_nlink is 2 as well, and the st_ino differ indeed.
So I have a patch which fixes this, but KLockFile is still VERY slow locking that file (i.e. every time I click on the view mode change button!), because of the slow testLinkCountSupport() code that the snipped code in the above if runs... Ouch I wanted to ask the author of the code about all this, but that's Waldo...