Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <1225030637.1138845616251.JavaMail.jira@ajax.apache.org>
Date: Thu, 2 Feb 2006 03:00:16 +0100 (CET)
From: "Suresh Thalamati (JIRA)" <derby-dev@db.apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-304) If by mistake you give he location
 for the db backup as the db itself , then windows created directories
 recursively until windows crashes!
In-Reply-To: <912105904.1116612893048.JavaMail.jira@ajax.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

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

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