At 11:24 PM 24/09/2006, Adam wrote:

>Firebird does not use a file system level exclusive write lock.

Oh yes it does - this is Superserver on Windows he is talking about
here. And the SS process *does* take an exclusive write lock. (It's
the actual reason, in fact, why the embedded server, which is a SS
process, excludes other connections!)

>For one, it wont work under classic, but apart from that you would not be
>able to use gstat etc if it was exclusively locked by a single process.

While it's true that classic does not take an exclusive write lock on
the database file, your observations about gstat, etc. are wrongly
premised. When there are no connections to a database, there are no
filesystem locks. When Superserver executes the *first* connection
request, it tries to acquire the filesystem lock. Remember, it is
the >>server<< that is operating on the file, not the connections.

If SS can't get the lock it requests, you get the error that Luc is reporting.

>But your problem is occurring because something is taking a file
>system level copy of the database file (in this case Volume Shadow
>Copy). Either switch it off, or move the database to a volume that
>does not need to be shadowed.

Well, it probably is something along these lines; but VSC, Nessus,
or any of these overriding applications is only going to *get*
read/write access to that block of disk if Superserver has no active
connections. The boot is then on the other foot.

>You will have problems if ANY process tries to directly copy the file.

Some copy programs don't take a write lock at all; whilst some
others take write locks at file level and yet others at sector
level. So, e.g. you can take a 7zip copy of a database file while
there are connected users, because SS already has the write lock and
7zip doesn't need it. So your copy will work and your database ops
will be unaffected (although the copy itself will be unpredictably
corrupt, of course!).

So, if Luc is seeing >>something<< barging in and locking the
database file while the Superserver already has the write lock, he's
seeing something pretty ruthless at work, quite possibly some
third-party app like Nessus. One does have to suspect VSC, on the
evidence, especially if Luc can establish that the problem *always*
occurs at or near a point where the volume shadowing service is
running. I think it first has to be established whether any client
connections are active when the problem occurs.

FYI, the reason for the exclusive write lock is that it prevents the
"path bug" that corrupts databases on Windows under SS in
InterBase. So - I wonder if Luc has checked whether the user
encountering the problem, i.e. the user who is causing the log entry
to be written, is attempting to connect with a "bad" path. If the
naughty user was first to connect, using some tool he downloaded from
the web, and used "c:data\mydb.fdb", then everyone using Luc's
application (with the >>good<< path string, "c:\data\mydb.fdb") will
get blocked out.

./heLen