Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Fri, 9 Nov 2012 01:12:12 +0000 (UTC)
From: "Mamta A. Satoor (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: <1816597808.89746.1352423532606.JavaMail.jiratomcat@arcas>
In-Reply-To: 
 <1762881484.10674.1305308027375.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Updated] (DERBY-5232) Put a stern README file in log and
 seg0 directories to warn users of corrpution they will cause if they touch
 files there
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/DERBY-5232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mamta A. Satoor updated DERBY-5232:
-----------------------------------

    Attachment: DERBY5232_test_patch1_stat.txt
                DERBY5232_test_patch1_diff.txt

I am attaching a patch for adding a junit test to check if the readme file gets created in the log directory when the log is directed to point to a different location than the default database directory. This change of log directory is done using the logDevice jdbc url attribute. eg
java -Dij.exceptionTrace=true org.apache.derby.tools.ij
connect 'jdbc:derby:db1;create=true;logDevice=../dellater';
exit;
The manual testing of the logDevice shows that readme file has been created inside the non-default log directory. 

The support for logDevice doesn't yet exist in our junit test framework. I have added changes in this patch to provide logDevice support inside junit.

But with my test, what I am finding is that even though the log got moved to the new location, the actual database files are not under the singleUse database directory. Not sure if my changes for logDevice support is causing this problem. Would appreciate any feedback from someone familiar with the junit framework in this area to see what might be wrong. In order to run the new added junit test, one can use following command
time java  -Dderby.tests.trace=true junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.engine.ReadMeFilesTest > runallOneTest.out 2>&1
The test above gives following results

$ time java  -Dderby.tests.trace=true junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.engine.ReadMeFilesTest
.
(emb)engine.ReadMeFilesTest.testReadMeFilesExist C:\p4clients\svnmain\client3\trunk\systest\out142\system\singleUse
used 820 ms F.
(net)engine.ReadMeFilesTest.testReadMeFilesExist C:\p4clients\svnmain\client3\trunk\systest\out142\system\singleUse
used 230 ms F
Time: 5.096
There were 2 failures:
1) testReadMeFilesExist(org.apache.derbyTesting.functionTests.tests.engine.ReadMeFilesTest)junit.framework.AssertionFailedError: assertIsExisting failed: C:\p4clients\svnmain\client3\trunk\systest\out142\system\singleUse\README_DONT_TOUCH_FILES.txt
        at org.apache.derbyTesting.functionTests.tests.engine.ReadMeFilesTest$1.run(ReadMeFilesTest.java:121)
        at java.security.AccessController.doPrivileged(AccessController.java:251)
        at org.apache.derbyTesting.functionTests.tests.engine.ReadMeFilesTest.assertIsExisting(ReadMeFilesTest.java:119)
        at org.apache.derbyTesting.functionTests.tests.engine.ReadMeFilesTest.testReadMeFilesExist(ReadMeFilesTest.java:101)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
        at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:117)
        at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:424)
        at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:441)
        at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
        at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
        at junit.extensions.TestSetup.run(TestSetup.java:25)
        at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
        at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
        at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
        at junit.extensions.TestSetup.run(TestSetup.java:25)
        at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
        at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
        at junit.extensions.TestSetup.run(TestSetup.java:25)
        at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
        at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
        at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
        at junit.extensions.TestSetup.run(TestSetup.java:25)
2) testReadMeFilesExist(org.apache.derbyTesting.functionTests.tests.engine.ReadMeFilesTest)junit.framework.AssertionFailedError: assertIsExisting failed: C:\p4clients\svnmain\client3\trunk\systest\out142\system\singleUse\README_DONT_TOUCH_FILES.txt
        at org.apache.derbyTesting.functionTests.tests.engine.ReadMeFilesTest$1.run(ReadMeFilesTest.java:121)
        at java.security.AccessController.doPrivileged(AccessController.java:251)
        at org.apache.derbyTesting.functionTests.tests.engine.ReadMeFilesTest.assertIsExisting(ReadMeFilesTest.java:119)
        at org.apache.derbyTesting.functionTests.tests.engine.ReadMeFilesTest.testReadMeFilesExist(ReadMeFilesTest.java:101)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
        at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:117)
        at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:424)
        at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:441)
        at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
        at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
        at junit.extensions.TestSetup.run(TestSetup.java:25)
        at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
        at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
        at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
        at junit.extensions.TestSetup.run(TestSetup.java:25)
        at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
        at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
        at junit.extensions.TestSetup.run(TestSetup.java:25)
        at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
        at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
        at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
        at junit.extensions.TestSetup.run(TestSetup.java:25)
        at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
        at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
        at junit.extensions.TestSetup.run(TestSetup.java:25)
        at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
        at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
        at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
        at junit.extensions.TestSetup.run(TestSetup.java:25)

FAILURES!!!
Tests run: 2,  Failures: 2,  Errors: 0


real    0m6.508s
user    0m0.000s
sys     0m0.015s


The existing test for logDevice jdbc url attribute are still in the old test harness
java\testing\org\apache\derbyTesting\functionTests\tests\store\LogDeviceTest.java
I can always go and do my testing for existence of readme files in that old harness test but it will be good to add the support for this attribute in junit framework.

                
> Put a stern README file in log and seg0 directories to warn users of corrpution they will cause if they touch files there
> -------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-5232
>                 URL: https://issues.apache.org/jira/browse/DERBY-5232
>             Project: Derby
>          Issue Type: Improvement
>          Components: Store
>    Affects Versions: 10.8.1.2
>            Reporter: Kathey Marsden
>            Assignee: Mamta A. Satoor
>             Fix For: 10.10.0.0
>
>         Attachments: DERBY5232_patch1_diff.txt, DERBY5232_patch1_stat.txt, DERBY5232_patch2_diff.txt, DERBY5232_patch2_stat.txt, DERBY5232_patch3_diff.txt, DERBY5232_patch3_stat.txt, DERBY5232_patch4_diff.txt, DERBY5232_patch4_stat.txt, DERBY5232_patch5_diff.txt, DERBY5232_patch5_stat.txt, DERBY5232_patch6_diff.txt, DERBY5232_patch6_stat.txt, DERBY5232_patch7_diff.txt, DERBY5232_patch7_stat.txt, DERBY5232_test_patch1_diff.txt, DERBY5232_test_patch1_stat.txt
>
>
> Users often on bad advice or desperation  touch or delete files in the log or seg0 directories (mostly log).
> I think it would be good for new databases and on upgrade that a file be created in these directories with a name like:
> TOUCHING_FILES_HERE_WILL_CORRUPT_DB_README.txt
> or some such to warn of the perils of doing this and the corrupting effects and how it can eliminate any possibility of salvage. It should also encourage users to make a zip backup of the database directory with no jvm currently accessing it before trying to do anything with the database if it appears to be already corrupt.  Also point to backup/restore documentation and encourage restore of a good backup into an empty directory if the database is corrupt.
> I'm not sure if it would help but it couldn't hurt.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira