[Box Backup] Feature requests

[Joe Krahn]

Ben Summers wrote:
...

>> 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.
My guess is that any OS not supporting it will not be using directories 
as mount points. In Windows, there are no directory mount points. But, 
Cygwin does have pseudo mount points, so it should emulate this if it is 
not part of Windows fstat. I'll check it out tonight, from Cygwin and MS 
VC. In any case, it should make no difference unless the one-file-system 
option is enabled.

>> 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?
If you have a shared/public disk, it is nice to see who owns a file. It 
could also be useful for allowing a user to browse backed-up directories 
based on their user/group/permission properties.

Normally, it is sufficient just to download a file and look at the 
user/group/mode/size you get back. So, if it's not easy, then I would 
skip it for now, but keep it in mind when expanding the attribute 
support, i.e. for MacOS. Maybe add the option of a file-download sending 
a list of components to return, one of them being the really big "data 
attribute".

...
>> 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.
Is there a matching WriteAttributes? (I didn't look yet -- I'm actually 
not all that interested in better attribute support; there are other 
more valuable things to work on.)
> 
> 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.
> 
Well, I would guess that most useful attributes are part of the UDF 
standard, along with ACL's, which may not be there. Most things would be 
pretty simple name/type things. ACL's are probably the most complicated 
due to the variable number of items.

Joe