[Box Backup] Win32 port (was: BoxBackup Server Side Management Specs (Draft0.01))

[Ben Summers]

On 2 Oct 2004, at 00:21, Chris Wilson wrote:

> Hi Ben and others,
>
>>> So far I have not needed to change any code, and I hope that I can
>>> maintain the Windows GUI semi-independently, only relying on some
>>> header files from Box.
>>
>> Sounds good. Are you talking to the server directly, or just writing
>> .conf files and using bbackupquery?
>
> My plan is for a very real-time, interactive client. Right now I'm 
> talking
> to the server, replacing and supplementing bbackupquery/bbackupd, in 
> order
> to learn how Box works.
>
> However, my longer-term plan is to communicate with bbackupd, both by
> modifying its config file, and using its existing socket, so that it
> becomes possible to see what the daemon is doing in real time (e.g. why
> hasn't it backed up File X)

I was thinking of adding a mechanism to do this would would open an 
external executable, and pipe in detailed descriptions of what it was 
up to.

>  along with live and permanent reconfiguration.

Wouldn't it be better to rewrite the .conf file and send a -HUP signal 
to do this? Certainly easier.

>
> These protocol extensions will undoubledly require major changes to
> bbackupd, and at that point I will be sure to make those changes 
> against
> CVS, in order to make them easier for you in integrate (hopefully you 
> will
> not object on principle to integrating them).

I welcome contributions to the code, obviously subject to quality and 
complexity considerations. I would suggest a quick email with proposed 
changes to me beforehand to check the design, though!

>
>> I shall add them in.
>
> Sorry, I was premature in suggesting this. They already appear to be in
> notes/windows_porting.txt (unless you have updated them since writing 
> that
> file, which was not apparent to me).

I wrote some additional notes which need editing in.

[snip]
>
>> Absolutely no need for this. If you look in the .conf file, you might
>> get a section like this:
>
> OK, I see what you're getting at. But this still doesn't solve the 
> problem
> for removable media. Perhaps in that case, a tool which can modify
> bbackupd.conf to create/remove stanzas for certain media, identified by
> GUID, could be useful?

Yes, that would be a perfectly acceptable way to do that. It would be 
better to adjust things so that the in-memory state is retained over 
restarts to accommodate that without having to query the entire store 
against the server after every device removal.

An alternative would be to allow bbackupctl to selectively enable and 
disable locations.

>
>> There is a separate object which does permissions and security info.
>> This just needs to be extended.
>
> Can you give me any more information on this, or point me to the 
> relevant
> parts of the Fine Manual? :-)

BackupClientFileAttribute.h, notes/windows_porting.txt

>
>> The streams that I were talking about contain bits of information 
>> about
>> the source of the file. So if it was downloaded from the internet, it
>> can be marked as suspicious, and the user gets a warning when they
>> execute it.
>
> Is this a Windows XP SP2-specific behaviour?

This use is, but multiple streams in a single file is something NTFS 
has done for years.

>  If so, then it seems strange
> to implement support for it in BoxBackup, but if there is a genuine 
> need,
> and it doesn't cause problems with restoration, then I'll consider it
> carefully.

I think generic support for multiple streams in a file is worth having 
anyway.

>
>> Yes. I'd like to get Mac OS X supported properly, for a start! (seeing
>> as it's my primary platform and everything)
>
> Me too, as I think streams would be useful for the above :-) But please
> don't regard this as serious pressure (yet), since I have a lot of 
> work to
> do on the GUI first.

There is other work which is higher up on the list, mainly to make it 
easier to use.

>
>>> Please do, I would be very interested to hear from anyone else who is
>>> working on Win32 support or a GUI, especially if they wish to
>>> collaborate,
>>> but at least to avoid duplication of effort.
>>
>> This does need coordination. I could get another mailing list started
>> if that would help?
>
> I would be interested to hear other list members' views on this. I 
> have a
> slight preference for keeping the discussion on this list, in order to
> involve the largest number of people, but if the die-hard Unix people
> object to this, then a new list would be much better than nothing :-)

As long as I don't lose subscribers unnecessarily, I'm happy.

Ben