[ http://issues.apache.org/jira/browse/DERBY-929?page=all ]
Suresh Thalamati updated DERBY-929:
-----------------------------------
Description:
As part of the backup process if a database already exists in the backup
path with same name already . it renames it to ..OLD and deleted it if backup
is successful. I think this was done to help users to replace old backups
easily with a new backup.
Unfortunate side effect is if db name happens to be same as another
directory in the databases path ,it will get deleted.
There were some negative comments about this behaviour in the book "Apache
Derby -- Off to the Races:" with example of C:/ as backup path and
WINDOWS as the database name.
Repro:
D:/
ij> connect 'sales;create=true';
ij> CALL SYSCS_UTIL.SYSCS_BACKUP_DATABASE('C:/') ;
If there is a "sales" directory in the C:/ already, backup will replace it
with the sales database.
Possible solutions:
1) Remove the replacking existing backup functionalty and throw a error if
there is already a file in the backup path with same name as database.
2) Throw error only if the file is not a database directory by checking
for service,properties
I like the first approach , users typically will create a backup path
with suffix as timestamp or something like that. If they want to really
replace , users can delete the existing backups. One problem is if some
existing customer is relying on this functionalty, it will break their backup
code.
Any suggestions ?
Thanks
-suresh
was:
As part of the backup process if a database already exists in the backup
path with same name already . it renames it to ..OLD and deleted it if backup
is successful. I think this was done to help users to replace old backups
easily with a new backup.
Unfortunate side effect is if db name happens to be same as another
directory in the databases path ,it will get deleted.
There were some negative comments about this behaviour in the book "Apache
Derby -- Off to the Races:" with example of C:/ as backup path and
WINDOWS as the database name.
Possible solutions:
1) Remove the replacking existing backup functionalty and throw a error if
there is already a file in the backup path with same name as database.
2) Throw error only if the file is not a database directory by checking
for service,properties
I like the first approach , users typically will create a backup path
with suffix as timestamp or something like that. If they want to really
replace , users can delete the existing backups. One problem is if some
existing customer is relying on this functionalty, it will break their backup
code.
Any suggestions ?
Thanks
-suresh
> Backup can delete a directory (another database or a plain directory) if
> database name matches with an existing directory in the backup path.
> -------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-929
> URL: http://issues.apache.org/jira/browse/DERBY-929
> Project: Derby
> Type: Improvement
> Reporter: Suresh Thalamati
> Priority: Minor
>
> As part of the backup process if a database already exists in the backup
> path with same name already . it renames it to ..OLD and deleted it if
> backup is successful. I think this was done to help users to replace old
> backups easily with a new backup.
> Unfortunate side effect is if db name happens to be same as another
> directory in the databases path ,it will get deleted.
> There were some negative comments about this behaviour in the book "Apache
> Derby -- Off to the Races:" with example of C:/ as backup path and
> WINDOWS as the database name.
> Repro:
> D:/
> ij> connect 'sales;create=true';
> ij> CALL SYSCS_UTIL.SYSCS_BACKUP_DATABASE('C:/') ;
> If there is a "sales" directory in the C:/ already, backup will replace it
> with the sales database.
>
> Possible solutions:
> 1) Remove the replacking existing backup functionalty and throw a error
> if there is already a file in the backup path with same name as
> database.
> 2) Throw error only if the file is not a database directory by
> checking for service,properties
> I like the first approach , users typically will create a backup path
> with suffix as timestamp or something like that. If they want to really
> replace , users can delete the existing backups. One problem is if some
> existing customer is relying on this functionalty, it will break their
> backup code.
>
> Any suggestions ?
> Thanks
> -suresh
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
