[Box Backup] bbackupquery.exe (R2549) requires a trailing backslash with a directory as a restore target

[Chris Wilson]

Hi Achim,

On Thu, 6 Aug 2009, Achim wrote:

>>  I'm not sure this is a bug.
>
> The only difference is a pending backslash or not:
>
> d:\restore\ works,
> d:\restore does not.
>
> The fix could be as simple as checking whether the backslash on the user 
> input exists, and add it in case it is missing.

I agree, but I don't want to because I don't recommend having a backslash 
there.

>>  The default action is to create the resume
>>  file in the directory above the requested one, i.e.
>>  d:\RESTORE.boxbackupresume in your case, to avoid polluting the restored
>>  directory with the resume info file.
>
> OK, I understand that reasoning. Why is the file name a concatenation of the 
> restore destination "RESTORE" and ".boxbackupresume"? I assume that 
> ".boxbackupresume" is the actual file name?

Yes, that is deliberate and exactly what is intended.

> The problem with the trailing backslash turns up here: perhaps with the 
> backslash, Box Backup tries to generate d:\RESTORE\.boxbackupresume and 
> without it it tries to generate d:\RESTORE.boxbackupresume?

Yes, that's correct.

> And shouldn't the file be created in the DataDirectory as specified in 
> bbackupd.conf anyway?

Well, it never has in the past, but you could make a case for it. 
bbackupd might be running as root or administrator while bbackupquery 
might not be, so it might not be possible to restore files at all in that 
case.

>>  In this case that attempt failed,
>>  and the question is why? Do you (the user on the command line) have
>>  permission to create that file in D:\?
>
> No, the user does not have permission on root folder level to create files. 
> Folders can be created. This could be a common scenario, where a corporate 
> user can only write to the D:\Data folder and its subfolders, but not into 
> d:\ itself.

That's the problem. Then create D:\RESTORE and restore to a subdirectory 
inside it.

>>  I have a feeling that this is a workaround that results in the resume
>>  file being created in the restored directory, which may not be
>>  desirable.
>
> That is what I also expect. If this is not desired, then perhaps there 
> should be an error checking that avoids the user being able to "polute" 
> the restore directory?

Probably, but it's the least of my worries at the moment. Feel free to 
file a bug report.

Cheers, Chris.
-- 
_____ __     _
\  __/ / ,__(_)_  | Chris Wilson <0000 at qwirx.com> - Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Ruby/Perl/SQL Developer |
\__/_/_/_//_/___/ | We are GNU : free your mind & your software |