[Box Backup] Feature requests

Ben Summers boxbackup@fluffy.co.uk
Thu, 9 Dec 2004 21:07:59 +0000


On 9 Dec 2004, at 18:33, Joe Krahn wrote:

> A couple of feature requests for bbackupquery; some simple, some not:
>
> 1) Allow the use of object-id instead of the name in all cases.
>    Instead of a '-i' flag, one could use a notation that is recognized
>    by the filename parser, such as '//ID:00000734'. I chose double
>    slashes, because it's the only way to ensure there is no filename
>    conflict - Linux allows all but '/' and NUL.

Interesting idea. And not a bad one either.

>
> 2) Add 'One File System' support. This is easy: just check st.st_dev
>    for rLocalPath, and don't save anything whose st_dev is different.
>    (I'm testing this now.)

Is st.st_dev going to work cross platform? I don't quite trust this, 
but can't find any references with a quick google which suggests it 
won't work.

>
> 3) It seems that extended attributes, like user/group, are saved.
>    If they are, how can I list them?

You can't at the moment. Attributes are embedded into the files (or the 
directory record if and only if the attributes change by the data 
doesn't) so to get the attributes the file would have to be downloaded. 
It would be possible for the server to extract that bit of information 
and send it, I suppose. (as attributes are encrypted separately.)

Is this really necessary?

>
> 4) File size: any way to list the decrypted file size? If not,
>    save this as another file attribute.

That would have to be added to the attribute block and decoded as 
above. Only the size in blocks is available, and this is not 
particularly reliable indication of size.

>
> 5) Maybe make attributes somewhat extensible, via a 'get_attributes'
>    function that makes it easy for users to modify without delving
>    into the main source code.

See BackupClientFileAttributes::ReadAttributes(). There's the basis of 
a scheme for extensible attributes, written with Win32 ACLs in mind.

How do you think a user might want to modify the attributes? Surely 
such things should be fairly generic (for each type of available 
attributes) and in the base distribution once written.

Ben