[Box Backup] Boxbackup suggestions

[Ben Summers]

On 29 Jan 2004, at 21:54, Eduardo Alvarenga wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Thu, 29 Jan 2004, Ben Summers wrote:
>
> <snip>
>
>> I started this as a proprietary product, not intending to release it 
>> to
>> the wider world. It only occurred to me a few months ago that open
>> sourcing it would be a good plan.
>
>  Nice approach.

I'm not sure if you mean that?

>
>> So, I haven't really been terribly worried about documenting all the
>> little funny bits that people have encountered, because the packaging
>> would take care of all these little things. And besides, *I* know what
>> they mean!
>
>  When the code is small, everything makes sense. Without documentation,
>  you might get lost one day and be forced to remember everything you
>  took a long time to develop.

Hence the contents of the notes directory, and the vast quantities of 
comments in the source files. With the debug version, it is really easy 
to see what has happened when you get an error. The code is not small 
already.

I would very much welcome comments on the code quality, and the 
sustainability of documentation and code.

>
> <snip>
>
>> The commands which modify the store are not useful. Either they would
>> be undone by bbackupd the next time it scanned the files, or it'd be
>> much easier just to let it get on with things.
>>
>> The basic read and navigation commands are all there -- see
>> bin/bbackupquery/documentation.txt
>
>  Another thing I miss: String-based listing.
>  Something like this:
>
>  --
>  ls rc.*
>  ls *.gif
>  ls foo?.*.c
>  --

Yes, might be handy.

>
>  How about ftp's mget feature? Any possibility to include this?
>  Or to make things better, implement recursive fetches from
>  files/directories directly via 'get':
>
>  --
>  get -r remotedir/ localdir/
>  get rc.* localdir/
>  get -r foo/bar/* localdir/foo/bar/
>  --

Implemented using the 'restore' command, and it's even restartable 
should your transfer get interrupted.


>
>>>    some switch to show the files in ftp format like:
>
> <snip>
>
>> Now this is more tricky. The way it works means that attributes would
>> have to be dug out of the stored files on the server, and finding the
>> size is another huge amount of code. I'm not entirely sure how much
>> extra information it gives anyway... this is a tool for assessing the
>> state of the store, and the information is shows does give very useful
>> information when you want to know what's going on. The actual contents
>> and attributes of the files aren't terribly useful.
>
>  Hm... maybe yes, maybe no. Let's suppose /var/log gets full. So we
>  delete old log files to save more space. Then, 15 minutes after this,
>  our boss asks for the last logs from the past 30 days. Oh!! it was
>  deleted, so what? Cry?

It is possible to fetch the old versions at the moment.

>
>  My idea is to make boxbackup a REAL recovery system and not just a
>  storage where the user might browse thru all their files, like he does
>  every day on his machine, and fetch any file or directory (even
>  recursively) like he was connected to a mirrored ftp server.

I'm not sure I quite follow.

>
>  The log files is an example, but let's complicate a little more. What
>  if your boss asks for the last pictures from last year's catalog
>  you've just deleted by his order? How to *list* and *get* the correct
>  files based on size, date, time, and type?

At the moment it's not easy, I admit. bbackupquery is a primitive tool 
which is the bare minimum required. This is not a finished project!

>
>> However, I can see the use of an ftp-like listing, so it's on the 
>> list.
>
>  Thanks. And please, put a pager on it like less/more, activated
>  automatically or not.

I'll see what I can do...

>
> <snip>
>
>>>  - Why have you chosen hex format by default?
>>
>> Constant width, compact representation, and clear display of byte
>> boundaries, all very helpful when debugging.
>>
>> Also, fits in very nicely with my intended use of the system.
>
> <snip>
>
>> The symbolic name to account number will be done by a management
>> system. And in practical terms, if you're using bbackupquery, it will
>> get all the info from the config file.
>
>  Hm.. management system. Any snapshot?

Not yet.

>
>>>  - An option to specify the allocation size in Mb or Gb and not only
>>>  in blocks. (I need a calculator everytime I want to insert/alter
>>>  any size. This is not cool).
>>
>> Yes, this should be done. Sort of annoying for me too.
>
>  I was almost certain you would agree with me ;-).

I use it too!

Ben