Bug #35804 Connector MXJ Corrupts the Existing Database
Submitted: 3 Apr 2008 14:54 Modified: 7 Jul 2011 18:23
Reporter: Danny Sporea Email Updates:
Status: Closed Impact on me:
None 
Category:Connector / MXJ Severity:S2 (Serious)
Version:5.0.8 OS:Any
Assigned to: CPU Architecture:Any

[3 Apr 2008 14:54] Danny Sporea
Description:
Connector MXJ Corrupts the Existing Database when a new packaging with an updated database is created and the old database is still uncompressed in the system.

How to repeat:
An application with an embedded MySQL database (using Connector MXJ) is distributed to the public. The first time the user runs the application, the MXJ Connector unzips the MySQL database, including the datafiles that contain a database with, let's say 7 tables.

At a later date, an update to the application is implemented and the Connector MXJ is repacked with a new database that is the old one (7 tables) plus 1 new table. The updated application, first time when it runs, is verifying the existing database version (uncompressed by the first release) and issues a CREATE TABLE statement to create the new table. The problem is, that the Connector MXJ corrupts the existing database by uncompressing the new data files that were included in the new packaging when first the new release is started. This is a problem when using InnoDB, because only the new .frm files are created, while the index and data file for InnoDB remains the old one.

Suggested fix:
Do not uncompress ANY files from the MXJ packaging IF the database folder is already present. Currently, only new files in the MXJ packaging are created in the old uncompressed database folder, which leads to existing database corruption.
[3 Apr 2008 16:19] Eric Herman
patch to address BUG#35804

Attachment: connector-mxj_bug_35804.diff (application/octet-stream, text), 4.88 KiB.

[7 Jul 2011 18:23] Paul Dubois
Fixed in 5.0.9