db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suresh Thalamati <suresh.thalam...@gmail.com>
Subject Re: [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!
Date Thu, 02 Feb 2006 18:40:47 GMT
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!!!
>>
>>
>>
> 
> 


Mime
View raw message