db-derby-dev mailing list archives

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

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

Bryan Pendleton commented on DERBY-2925:
----------------------------------------

Thanks Ramin, that explanation makes complete sense to me.

I don't have a strong opinion about this deleteFile issue. I think it is nice of the tool
to avoid leaving partial files around. The only possible problem I can see is that I think
there could be a scenario in which the export fails partway through, and it's not obvious
which row of data caused the failure, but by looking at the end of the partial file, the user
can see which rows were successfully written just *before* the failure, and gain a clue about
where the failure is occurring.

So I don't have any particular guidance to give. I think the new deleteFile behavior is useful,
but I think it would also be fine to remove that portion of the patch and handle it by changing
the tests as you suggested.


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


Mime
View raw message