Given the bad result at least in some environment it would be nice to
catch whatever cases we can. Seems like comparing the paths either
directly or using the absolute path mechanism is easy.
The creating a file approach also looks like it is promising, i don't
understand the overhead.
Suresh Thalamati (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-304?page=comments#action_12364909 ]
Suresh Thalamati commented on DERBY-304:
----------------------------------------
I tried the repro for this bug on my laptop with Windows XP , backup failed
while copying the directories., with the error:ERROR XSRS5: Error copying file
(during backup) from C:\maildb to c:\maildb\maildb.
OS did not crash for me..
I think it is very rare any user will make mistake of giving backup path
same as database home or one of its subdirectories. But I agree it might be
nice to throw a better error message, but that might add some addtional
restrictions or overhead.
Some thought one possible way to fix this::
1) Get absolute paths for both the database home directory and the backup
directory then find if backup path is a subdirectory under the database
directory. Problem with this approach is :
a) Backup would always require read permission for "user.dir" when run under security manager.
b) If there are symbolic links involved , this fix will not work.
2) Add a counter to keep track how many level of deep the directories are being created from the backup
directory while doing the copy. If the directory level is deeper than the database normally has then throw
error. This will work if user create backup under <dbname>/jar or <dbname> but if the given
backup path is under "log" and "seg0" then we can not identify this case becuase these
directoties are not copied any more.
3) At the start of the backup create a uniue file using a UUID under the backup directory , then search for that file under the database home directory. If that file is not found then one can be sure backup path is not mapping to a subdirectiory of database directory. Delete the new file created and then proceed with the backup. I think this fix will work , but there is overhead of searching through all the files under the database directory for a error case.
4) Don't bother to fix it , No one is going hit this problem again :-)
Any suggestions ?
Thanks
-suresht
If by mistake you give he location for the db backup as the db itself , then
windows created directories recursively until windows crashes!
-------------------------------------------------------------------------------------------------------------------------------------------
Key: DERBY-304
URL: http://issues.apache.org/jira/browse/DERBY-304
Project: Derby
Type: Bug
Components: Store
Versions: 10.1.1.0
Environment: With JDK 142 on Windows XP
Reporter: Manjula Kutty
Priority: Minor
If by mistake you give he location for the db backup as the db itself , then windows created directories recursively until it crashes!
Repro:
CallableStatement cs = conn.prepareCall("CALL
SYSCS_UTIL.SYSCS_BACKUP_DATABASE_AND_ENABLE_LOG_ARCHIVE_MODE(?, ?)");
cs.setString(1, "c:/maildb");
cs.setInt(2, 1);
cs.execute();
cs.close();
result:
C:\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\.....................
Until windows can not show the path!!!
