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, 23 Oct 2012 03:45:12 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_patch2_stat.txt
                DERBY5232_patch2_diff.txt

I have another patch which has following changes compared to the first patch
1)It does not hard code the readme contents inside the java file. Instead, it uses existing
mechanics to store that text inside messages.xml so it will get translated.
2)The code now handles StandardException as pointed out by Knut.
3)I have named the readme file as README_DONT_TOUCH_FILES.txt
4)I have been able to create README_DONT_TOUCH_FILES.txt at the top level(db level) and at
log level. But I have not been able to find yet the place in the code to create a README_DONT_TOUCH_FILES.txt
at seg level and will greatly appreciate help here. I thought the correct location for creating
this file in the code will be in store.access.RAMAccessManager:boot() method right
after 
xactProperties = new PropertyConglomerate(tc, create, startParams, pf);
The above line creates seg0 directory and creates the first heap file in it. And it seems
like, right after the seg0 directory is created, we should create the README_DONT_TOUCH_FILES.txt
but to create a file, we need access to StorageFactory which has the new method newStorageFile()
to create a new file and I do not know how to get hold of StorageFactory inside RAMAccessManager.
It is possible that I am looking at wrong place for adding the code. Would appreciate help
from someone more familiar with this part of the code.
5)Even though I have added the text is messages.xml with new lines, when it gets written into
README_DONT_TOUCH_FILES.txt, I find that the newlines are lost and everything is added as
one long line. I am not sure yet what I could be doing wrong.
             <msg>
                <name>M005</name>
                <text>
# *************************************************************************
# ***              Do not touch files in this directory!                ***
# *** CHANGING THE CONTENT OF THIS DIRECTORY MAY CAUSE DATA CORRUPTION. ***
# *************************************************************************</text>
                <comment>Translators: Please translate the ALL CAPS words.</comment>
            </msg>

I still need to add more comments but wanted to put the patch out for review and for help
with couple items I haven't figured out yet. Thanks.

                
> 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

Mime
View raw message