Subject Re: Permission problem
Author Adam
--- In firebird-support@yahoogroups.com, "Ann W. Harrison"
<aharrison@...> wrote:
>
> Adam wrote:
>
> > Worse still, and although I can not understand how it is possible,
> > there have been reports about the source database being corrupted by
> > copying it using a file system level copy utility.
> >
>
> Consider this case: you store a record in a table with an index.
> The database has to add a page to the table to hold the new record.
> To do so, it changes a page information page to show that the page
> is now in use, and makes an entry on a pointer page for the table
> that indicates that the page belong to the table. Then a new
> entry is made in the index. Both the pointer page and page
> information page occur before the new data page and the index
> page in the data file.
>
> To maintain on-disk consistency, the page are written in this
> order: page information page, data page, pointer page, index
> page. If your copy is unfortunate and gets the old versions
> of the page information page and the pointer page but the new
> versions of the index and data pages, an lookup that should
> return the new record will get a corruption error of something
> like "page 0 wrong type, expected 5 encountered 1". Zero is
> the value set in empty slots on a pointer page.

Would this be a corrupt 'destination' database?

The copy gets the mish mash of data, info, pointer and index pages (or
in simpler terms, corruption). This would mean when you attempt to
read the record in the destination, you would get the corruption
error, but unless my brain is not on (pretty good chance), that would
not affect the source database.

Perhaps some file system tools place read exclusive lock (or something
like that) on part of the source file while they are reading a
particular page (file system concept of page, not firebird page), and
this could prevent a write to the database file if the database wanted
to write that particular page to disk, but that is just speculation on
my part.

*******

> In short, don't copy a running database.

*******

Agreed. If you can't be sure the backup itself isn't corrupt, then
what is the point anyway?

Adam