[Box Backup] Feature requests

[Ben Summers]

On 10 Dec 2004, at 00:29, Joe Krahn wrote:

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

I think that will be enabled by default, and explicitly disabled. Some 
things won't work properly if a location spans multiple filesystems.

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

I've added it to the list as a low priority option.

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

Of course there is!


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

Contributed code for these is welcomed.

Ben