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

[Ben Summers]

On 30 Sep 2004, at 20:13, Chris Wilson wrote:

> Hi Ben,
>
>>> I second the call for duplicate file detection :-)
>>
>> Unfortunately there's only one of me.
>
> Sorry, I'd be happy to help out when I've made some progress on the GUI
> and Windows port and I've got a bit more time.

Great.

>
>> Before you start changing code, it will be much easier if you work on 
>> a
>> checkout of my CVS repository. The released code is run through a
>> script which does various modifications like adding the license at the
>> top of each file, so patches from released code are not as easy to
>> integrate as they might be.
>
> 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?

>  However, there does seem to be a fair amount of
> auto-generated and platform-dependent stuff that might require work on 
> the
> build system to integrate properly. I will tackle that when I have
> something worth integrating :-)

Yes, the build system might need a little work.

>
>> I also have some extended notes on porting to Win32, if anyone wants a
>> copy. (I have already sent one to Chris.)
>
> Those notes are so useful that perhaps they should be in the notes
> directory?

I shall add them in.

[snip]
>> Seriously, a Win32 server is unlikely as it depends on the behaviour 
>> of
>> the UNIX filesystem. On Windows you can't delete or move another file
>> over a file which is currently open.
>
> Well, I suspect I'll have to dive into device drivers to make open file
> support work, so maybe I can fix this at the same time, or make it 
> easier
> for the next person. Personally I have no desire to run a server on
> Windows.

I can't see why you'd want to, given that Windows would give you 
absolutely no advantage and cost money.

[snip]
>>> * support for drive letters
>>
>> I would have thought that the existing mechanism of backup locations
>> will handle this reasonably well.
>
> What mechanism is that? There seems to be an implicitly assumed special
> object at the root of the filesystem with the name "/" (unless I
> misunderstand). That doesn't seem to map very nicely to Windows drive
> letters, especially when it comes to removable devices. Perhaps I could
> have a virtual root directory with "/c:/", "/d:/", etc. underneath it.

Absolutely no need for this. If you look in the .conf file, you might 
get a section like this:

BackupLocations
{
	home
	{
		Path = /home
	}
	usr-local
	{
		Path = /usr/local
	}
}

Each location is independent. The names don't even have to match the 
names of the path. In the root directory of the store, you get the 
location name, and then all the files below it. So under Windows you'd 
simply have something like

BackupLocations
{
	disc1
	{
		Path = C:\
	}
	system-disc
	{
		Path = D:\
	}
}

Nothing complex or weird necessary.

>
>> This requires multiple streams to be implemented, which currently
>> there's no neat way of doing. Now that WinXP SP2 uses multiple streams
>> to store file security information, it's probably required for Win32 
>> as
>> well. And I might as well support sparse files while I'm at it.
>
> I don't plan to back up security information directly as a binary 
> stream,
> because I suspect that it would be useless if restored onto a different
> machine or installation. Perhaps I could use such a stream for a 
> textual,
> machine-independent representation of all the security information
> associated with a file, and it might be the best way to support that 
> kind
> of detailed security data.

There is a separate object which does permissions and security info. 
This just needs to be extended.

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.

>  Do you have concrete plans to implement this at
> some point?

Yes. I'd like to get Mac OS X supported properly, for a start! (seeing 
as it's my primary platform and everything)

>
>> A few other people have a bit of a start on this. I will try and put
>> everyone in touch with each other.
>
> 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?

Ben