[
https://issues.apache.org/jira/browse/DERBY-5232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482417#comment-13482417
]
Knut Anders Hatlen commented on DERBY-5232:
-------------------------------------------
Hi Mamta,
I don't know why the newlines disappear. They seemed to be there when I tested
the patch. Maybe it's a Windows vs Unix line ending issue? I had another
problem, though. The files were stored in UTF-16, so less complained they were
binary files and wouldn't open them. They'd probably be easier to access if
they were stored in UTF-8.
Some stylistic comments:
- The indentation used in the new code varies between pure spaces, pure tabs
and mixed tabs/spaces. It would be easier to see the structure of the code in
the patch with a consistent indentation style.
- The code that produces the readme files is repeated three times. It would be
good if it could be refactored so that there's a single implementation.
- When writing the readme file, the file handle is closed inside the try block,
in the catch block and in the finally clause. In the common case, it will be
closed twice. It's probably sufficient to close it in the finally clause.
> 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
> Attachments: DERBY5232_patch1_diff.txt, DERBY5232_patch1_stat.txt,
> DERBY5232_patch2_diff.txt, DERBY5232_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
