Return-Path: X-Original-To: apmail-incubator-callback-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-callback-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id B71C3C73B for ; Fri, 11 May 2012 10:08:22 +0000 (UTC) Received: (qmail 9018 invoked by uid 500); 11 May 2012 10:08:21 -0000 Delivered-To: apmail-incubator-callback-dev-archive@incubator.apache.org Received: (qmail 8785 invoked by uid 500); 11 May 2012 10:08:20 -0000 Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: callback-dev@incubator.apache.org Delivered-To: mailing list callback-dev@incubator.apache.org Received: (qmail 8739 invoked by uid 99); 11 May 2012 10:08:19 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 11 May 2012 10:08:19 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED,T_RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 11 May 2012 10:08:16 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116]) by hel.zones.apache.org (Postfix) with ESMTP id E82C749077D for ; Fri, 11 May 2012 10:07:55 +0000 (UTC) Date: Fri, 11 May 2012 10:07:55 +0000 (UTC) From: "Neil Harding (JIRA)" To: callback-dev@incubator.apache.org Message-ID: <217335926.53880.1336730876041.JavaMail.tomcat@hel.zones.apache.org> In-Reply-To: <538346075.48930.1336646642240.JavaMail.tomcat@hel.zones.apache.org> Subject: [jira] [Commented] (CB-684) WebKit database restore on iOS5.1 corrupts large databases MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/CB-684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13273149#comment-13273149 ] Neil Harding commented on CB-684: --------------------------------- Thanks for your response. Obviously it's disappointing you're not going to look at this. Although I understand we are an edge case but aside from this issue the app runs well with a large database and in Phonegap 1.4.1 there was no issue. Could there at least be a hook somewhere to turn off the backup/restore process? We are developing an enterprise app where we are in complete control of the iPads that are deployed to and can stipulate that there should always be ample remaining space so iOS will never run low on space and clear up the /library/caches folder. We want to continue with Cordova and benefit from api updates and bug fixes, but this is a real blocker at sticks us at 1.4.1. Thanks > WebKit database restore on iOS5.1 corrupts large databases > ---------------------------------------------------------- > > Key: CB-684 > URL: https://issues.apache.org/jira/browse/CB-684 > Project: Apache Cordova > Issue Type: Bug > Components: iOS > Affects Versions: 1.6.1 > Environment: iOS5.1 > Reporter: Neil Harding > Assignee: Shazron Abdullah > Priority: Critical > Labels: database, ios, sqlite, webkit > > The backup and restore process for WebKit databases on iOS5.1 to copy databases from the /library/caches folder to /documents/backup is corrupting large databases. > I have a 1Gb sqllite databases, this is is because there will be a lot of data in the app and to get around the 5mb quota limit for Websql databases on iOS a large pre populated .db file is copied over to /library/caches on app start up in didFinishLaunchingWithOptions if it doesn't already exist. This 'reserves' the footprint of the database as sqlite doesn't unallocated space when deleting rows, the data is cleared out and the app can start off without any quota errors. > When the app terminates and the backup process runs to copy the .db file to /documents/backup it doesn't complete the process successfully (possibly killed by iOS before the file is fully written?) and the resulting file .db is much smaller (~200mb) and corrupt. > When the app runs next time the .db is copied from /documents/backup to /library/caches ok, but the damage is already done. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira