On Friday 2001-09-21 at 18:56:21 +1000, Helen Borrie wrote:

> At 10:38 AM 21-09-01 +0200, you wrote:
>
> > >
> > >Did someone kick the plug out of the power socket? Tried to
> > >file-copy the database file whilst the server was running? Tried
> > >to overwrite the database file? Tried to call a buggy UDF?
> > >
> > >What does interbase.log say?
> >
> >
> >I have had the same message nad would like to know why. WIll it
> >happen when someone tries to copy the db while the gdb file is in
> >use?
>
> Yes, possibly, because it will lock the sector of the disk it is
> currently copying.

Surely, this is a Windows thing? Or at least a non-Unix thing.
Under Unix, generally speaking, and file permissions allowing, any
process can read any file at any time, locks or no locks. This is
because file locking in Unix (or Linux at least) is mostly or always
advisory locking. I haven't yet come across mandated locking of files
or ranges within files as I have in Windows.

One of the consequences of the Unix way of doing file locking is that
system maintenance tasks, such as backup, are often a good deal
easier. For instance, a log file could be moved to a backup directory
by one process while another is busy writing to it. Try that in
Windows. :-) Or a temporary file can be deleted ("unlinked") by one
process while that process or another process still has it open for
reading or writing. That's something else you won't have much luck
trying to do in Windows...

Of course, as far as backup is concerned, certain types of files, such
as database files, can't be usefully backed up while the associated
application (InterBase server, for instance) is active.


David Trudgett