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

[Achim]

Hello Chris:

On 05/08/2009 00:42, Chris Wilson wrote:
>> query > ls
>> 00000002 -d---- BACKUPTEST
>> query > restore BACKUPTEST d:\RESTORE
>> WARNING: Failed to open file: d:\RESTORE.boxbackupresume: Acceso
>> denegado.
>> (5)
>> WARNING: Exception thrown: CommonException(OSFileOpenError) at
>> FileStream.cpp(84)
>> ERROR: Failed to save resume info file 'd:\RESTORE.boxbackupresume':
>> Common OSFileOpenError (Can't open a file -- attempted to load a
>> non-existant config file or bad file referenced within?)
>> ERROR: Unknown error during restore.
>
> 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.

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

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? And 
shouldn't the file be created in the DataDirectory as specified in 
bbackupd.conf anyway?

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

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

Best regards, Achim