Mike Matrigali wrote:
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.
Overhead in create file approach is just searching though the datbase
directory to make sure the file we created is not threre ? May be
this little exta search does not really matter, considering backup is
I/O bound any way.
Thanks
-suresht
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!!!
