[
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
DERBY5232_test_patch2_diff.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) {
removeDirectory(logDevice);
}
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()
{
TestConfiguration.setCurrent(old);
}
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: 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,
> 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:
> 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
