Comment 4 for bug 117730

dkg (dkg0) wrote :

This looks like it's still a problem on hardy to me. The following was gathered from an up-to-date ubuntu 8.04 installation with a user's home directory mounted via CIFS

Even worse than just sqlite3, since firefox 3 uses sqlite internally, it looks like it's making firefox fail to function at all when my home directory is mounted via CIFS.

When this user starts firefox, firefox just opens a small browser window, and doesn't even respond to clicks on the green triangle in the address bar.

When i shutdown firefox, wipe out ~/.mozilla and restart firefox to make it create a new profile directory, it still misbehaves. Looking at the freshly-created ~/.mozilla, it contains the following files:

.mozilla/firefox/k81epmi7.default/places.sqlite
.mozilla/firefox/k81epmi7.default/places.sqlite-1.corrupt
.mozilla/firefox/k81epmi7.default/places.sqlite-2.corrupt
.mozilla/firefox/k81epmi7.default/places.sqlite-3.corrupt
.mozilla/firefox/k81epmi7.default/places.sqlite-4.corrupt
.mozilla/firefox/k81epmi7.default/places.sqlite-5.corrupt
.mozilla/firefox/k81epmi7.default/places.sqlite.corrupt

I made a very simple sqlite3 db on /tmp (which is ext3 on this system), and copied the file to the cifs-mounted directory.

then i ran a simple command to add a row to a table against each copy, using strace.

I'm attaching the differences between the straces.

You can see that the sqlite3 process running against the cifsmount has its second byte-range locking request fail:

+fcntl64(3, F_SETLK64, {type=F_WRLCK, whence=SEEK_SET, start=1073741824, len=1}, 0xbfbcfc24) = 0
+fcntl64(3, F_SETLK64, {type=F_WRLCK, whence=SEEK_SET, start=1073741826, len=510}, 0xbfbcfc24) = -1 EACCES (Permission denied)

though the one running on ext3 has both locking byte-range locking requests succeed:

-fcntl64(3, F_SETLK64, {type=F_WRLCK, whence=SEEK_SET, start=1073741824, len=1}, 0xbf9549d4) = 0
-fcntl64(3, F_SETLK64, {type=F_WRLCK, whence=SEEK_SET, start=1073741826, len=510}, 0xbf9549d4) = 0

I don't know if this should be listed as a bug in the kernel's cifs module, a bug in sqlite, a bug in samba, or what.

fwiw, the server this is applied against is an older samba daemon on a machine that is touchy to upgrade for a number of reasons.

This ticket claims to be closed ("fixed in gutsy") but it's not clear to me how it was fixed (i see no link to a changelog). Suggestions for next steps?