db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta A. Satoor (JIRA)" <j...@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
Date Tue, 13 Nov 2012 02:47:13 GMT

     [ 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_patch2_stat.txt

I have changed the earlier test patch to use getDefaultDatabaseName() to find the database
path to look for the readme files inside the database directory and inside the seg0 directory.
Also, I have added one helper method in PrivilegedFileOpsForTests class and used one of the
existing  methods in that class to find the readme files. Since a run of network server after
embedded does not really recreate the database, the test now only runs in embedded mode and
ensures that 3 readme files get created correctly.

The issue that's left now is deleting the log files from the new log location set by the logDevice
attribute. I thought I would be able to do that in the DropDatabaseSetup.removeDatabase()
method with the following code
        String logDevice = config.getConnectionAttributes().getProperty("logDevice");
        if (logDevice != null) {
But "logDevice" property comes back as null as if that property was never set. Through debugging,
I am finding that the reason behind this is TestConfiguration.getCurrent() by this point has
lost the TestConfiguration used to do the testing and hence we have lost the logDevice property
from the available properties. Maybe that is the right thing to happen but I thought the tearDown
of DropDatabase.tearDown() should get called before ChangeConfigurationSetup.tearDown() which
is where the TestConfiguration used by the test gets overwritten. The code for ChangeConfigurationSetup.tearDown()
is as follows for reference.
    protected final void tearDown()
Maybe I am trying to solve it in the wrong place but I don't understand why the current configuration
gets overwritten before all the decorator have a chance to do their on tear down. Would appreciate
someone explaining the current behavior.

In the mean time, I will investigate Knut's suggestion that may be the log directory deletion
should happen in the Decorator returned by Decorator.logDeviceAttributeDatabase(). I will
try to investigate that.

> 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:
>            Reporter: Kathey Marsden
>            Assignee: Mamta A. Satoor
>             Fix For:
>         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, DERBY5232_test_patch2_diff.txt, DERBY5232_test_patch2_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:
> 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

View raw message