db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ramin Moazeni (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2925) Prevent export from overwriting existing files
Date Mon, 23 Jul 2007 18:56:31 GMT

    [ https://issues.apache.org/jira/browse/DERBY-2925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514725

Ramin Moazeni commented on DERBY-2925:

Hi Bryan,

Thanks for looking at the patch.
Correct...I added the deleteFile(...) after I got errors running the tests. In this case
i18n/iepnegativetests_ES.sql was failing and the reason for that was that in executing
the following call:
ij> call SYSCS_UTIL.SYSCS_EXPORT_QUERY('select * from iep.t1','t1.dat' , null, null, 'NOSUCHCODESET')
ERROR XIE0I: An IOException occurred while writing data to the file.
ERROR XJ001: Java exception: 'NOSUCHCODESET: java.io.UnsupportedEncodingException'.

the output file gets created even though there is an exception and therefore, the rest of
the tests were failing because
the file exists. 

I can remove the deleteFile(...) from the patch but to resolve the test errors, I think another
way is to have
a java stored procedure in in the .sql test to delete the file or simply use different filenames
in each
call to SYSCS_UTIL.SYSCS_EXPORT_... when we know a partially-written file will get created.


> Prevent export from overwriting existing files
> ----------------------------------------------
>                 Key: DERBY-2925
>                 URL: https://issues.apache.org/jira/browse/DERBY-2925
>             Project: Derby
>          Issue Type: Sub-task
>          Components: Security, Tools
>    Affects Versions:,,,
>            Reporter: Kathey Marsden
>            Assignee: Ramin Moazeni
>         Attachments: DERBY-2925v0.diff, DERBY-2925v0.stat, DERBY-2925v1.diff, DERBY-2925v1.stat,
DERBY-2925v2.diff, DERBY-2925v2.stat
> Export should not overwrite existing files, but rather insist that the user remove them
before writing to the file.  This will help prevent accidental or intentional corruption of
the database with export.  This may introduce a compatibility issue with export but because
export is usually an attended utility and not typically invoked as part of an application,
I think the risk is worth the additional security this will provide.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message