[
https://issues.apache.org/jira/browse/DERBY-5232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13483517#comment-13483517
]
Mamta A. Satoor commented on DERBY-5232:
----------------------------------------
To solve the UTF-8 vs UTF-16 problem mentioned by Knut(1), am I right that I
should use
randomAccessFile.writeUTF(fileContent);
rather than
randomAccessFile.writeChars(fileContent);
How would I verify that we the writeUTF call, the file has indeed been saved in
UTF-8 format. I thought if I opened the file in notepad and used "save as", in
the encoding dropdown, I will see UTF-8 rather than ASCII, but I still see
ASCII even when the file gets it contents with writeUTF call rather than
writeChars call. Thanks
(1)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.
> 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,
> DERBY5232_patch3_diff.txt, DERBY5232_patch3_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
