[EMAIL PROTECTED] writes: > In the latest versions of SQLite (3.3.0 and later) you can provide > SQLite with customized locking code at run-time. So you can > easily add AFS support that uses whole-file locking instead of > the goofy byte-range stuff I have to do for Win95.
That's fantastic. One other thing -- and this is absolutely not SQLite's concern, and if it isn't handled it's no big deal -- AFS's handling of whole-file locks is great, but currently the way it handles byte-range locks is extremely dangerous: it always "pretends to" grant them. That's right, it always returns success on a byte-range lock that covers anything less than the whole file. Terrifying. I recently confirmed that you can easily corrupt databases this way. Would it be possible for the on-disk database file format to be able ot signal that a particular kind of locking must be used? Could it be done in a way that would prevent older versions of SQLite from accidentally opening the file (ie appear incompatible)? If this is not possible or seems like a bad design choice, I completely understand. I am not at all happy about the fact that AFS pretends to grant byte-range locks (the correct behavior should be to always refuse them if they cannot be supported), and this is really not SQLite's problem. > If you can wait, you might want to add AFS locking to that > module as another option. I'd be happy to. Please let me know when the right time to do this would be. - a -- PGP/GPG: 5C9F F366 C9CF 2145 E770 B1B8 EFB1 462D A146 C380
