03.04.2012 10:44, Vlad Khorsun wrote:
To not read whole database searching
for the not encrypted pages after restart i offer to store last encrypted
page number
at header page (also, obviously, we need to store encription state on the
header
such as clear, encrypted, encryption is in
On 04/03/12 12:49, Dimitry Sibiryakov wrote:
03.04.2012 10:44, Vlad Khorsun wrote:
To not read whole database searching
for the not encrypted pages after restart i offer to store last encrypted
page number
at header page (also, obviously, we need to store encription state on the
header
Hello, Vlad!
Tuesday, April 3, 2012, 12:44:07 PM, you wrote:
VK Encryption must be resistent to the database shutdown\server restart
and so on.
VK Therefore it must be restartable. As we going to add encrypted flag for
each page
VK we can know pages that already encrypted. To not read
On 04/03/12 13:03, Dmitry Kuzmenko wrote:
Hello, Vlad!
Tuesday, April 3, 2012, 12:44:07 PM, you wrote:
VK Encryption must be resistent to the database shutdown\server restart
and so on.
VK Therefore it must be restartable. As we going to add encrypted flag for
each page
VK we can
VK Encryption must be resistent to the database shutdown\server restart
and so on.
VK Therefore it must be restartable. As we going to add encrypted flag for
each page
VK we can know pages that already encrypted. To not read whole database
searching
VK for the not encrypted pages
I meant 12345 checksum that was fixed since InterBase 5. So, page
checksums are not guards of the pages for a long time. They are just
indicators, that if there no 12345, page can be considered as crap.
Anyway not good crypt indicator - in some rare cases it can be 12345 on
encrypted page.
As
