[ 
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.

Thanks
Ramin

> 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: 10.1.2.1, 10.2.2.0, 10.3.1.3, 10.4.0.0
>            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.

Reply via email to