From dev-return-29981-apmail-jackrabbit-dev-archive=jackrabbit.apache.org@jackrabbit.apache.org Tue Nov 23 21:42:10 2010 Return-Path: Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: (qmail 83331 invoked from network); 23 Nov 2010 21:42:10 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 23 Nov 2010 21:42:10 -0000 Received: (qmail 64265 invoked by uid 500); 23 Nov 2010 21:42:42 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 64208 invoked by uid 500); 23 Nov 2010 21:42:41 -0000 Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@jackrabbit.apache.org Delivered-To: mailing list dev@jackrabbit.apache.org Received: (qmail 64201 invoked by uid 99); 23 Nov 2010 21:42:41 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 23 Nov 2010 21:42:41 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.22] (HELO thor.apache.org) (140.211.11.22) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 23 Nov 2010 21:42:39 +0000 Received: from thor (localhost [127.0.0.1]) by thor.apache.org (8.13.8+Sun/8.13.8) with ESMTP id oANLgHrw013459 for ; Tue, 23 Nov 2010 21:42:18 GMT Message-ID: <4187753.272501290548537805.JavaMail.jira@thor> Date: Tue, 23 Nov 2010 16:42:17 -0500 (EST) From: "Bernd Eckenfels (JIRA)" To: dev@jackrabbit.apache.org Subject: [jira] Created: (JCR-2819) FileDataStore not crash safe MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org FileDataStore not crash safe ---------------------------- Key: JCR-2819 URL: https://issues.apache.org/jira/browse/JCR-2819 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Affects Versions: 2.1.2 Environment: All Reporter: Bernd Eckenfels Priority: Minor The FileDataStore.addRecord() does create a temporary file and rename it to the final location. On a crash, this can result in a file which is renamed but the content is still empty. This especially happens on systems where data in the filesystem is not journaled. You can resolve this problem by calling the fdsync() method of the operating system before renaming the file. Typically in Java this is done by first flushing all the Java buffers (i.e. calling flush() on the highest output stream), and then using the getFD().sync(); method on the FileOutputStream. Note: this introduced some delay/additional IO load on the system, therefore I think it might be best to make it configurable. But I think in some environments the additional reliability is badly needed. Sample patch without configuration parameter added. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.