[Box Backup] Long path names, open files, etc

[Scott McNee]

Hi Chris,

With Open files what if we head down the path of a DLL ? I dont know if 
that is messy or not, but I have some VSS stuff in a windows programming 
language that could be made into a dll.
That way box code would not be reliant upon any M$ products and would 
only implement the VSS stuff if the DLL was present ?

You could expand the box interface to support multiple OS's in a modular 
way. That way as a developer wanted to support say LVM Snapshots on 
Linux they would only have to provide a shared object and not have to 
get too involved with the Box code.

Box could also run in a failsafe mode. Where it tries to use one of the 
plug ins but if something happens it can revert back to normal copy or 
something. Realistically it is only the paths that box looks at that are 
the problem?
ie. Some sort of sequence as follows.

-> Backup Start Event
-> Trigger Plug-in (Pass Relevant (Root) volumes)
                <- Plug-in passes relevant mount info for snapshot volume.
-> Mount Info Verified on Fail use default path. (No snapshots)
-> Backup as normal from snapshot volume
-> backup completes
-> Plugin cleans up snapshot.

There are some other backup tools (Commercial) that have a similar setup.

Scott.


Chris Wilson wrote:
> On Mon, 30 Mar 2009, Achim wrote:
>
>>>> On Windows, open files which are exclusively locked cannot be
>>>> opened, even for backup, so they are skipped with a warning. See
>>>> this ticket for a workaround: http://www.boxbackup.org/trac/ticket/13
>>
>> VSS would be an amazing addition to Box Backup! It allows you to backup
>> Outlook PST files without problems. This filetype is probably
>> (unfortunately) one of the most mission critical pieces out there, given
>> how much people rely on e-mail these days.
>>
>> Is the coding very complicated, or would it possibly break Box on 
>> platforms
>> other than Windows?
>
> Unfortunately it is very complicated, or it would have been done by 
> now. There are a huge number of interfaces, it behaves differently on 
> XP and 2003 (and probably vista), and so far I've only been able to 
> develop code with Visual Studio, not with my Windows normal 
> development platform of vi + mingw on Windows 2000. It doesn't even 
> work on Windows 2000.
>
> It's also non-free in the sense that we can't distribute the SDK 
> needed to compile Box with this function enabled, so anyone who wants 
> to do so would have to download that SDK from Microsoft.
>
> Cheers, Chris.