[Box Backup] Boxbackup suggestions

[Eduardo Alvarenga]

-----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=
=20
> the wider world. It only occurred to me a few months ago that open=20
> sourcing it would be a good plan.

 Nice approach.

> 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=20
 took a long time to develop.

<snip>

> The commands which modify the store are not useful. Either they would=20
> be undone by bbackupd the next time it scanned the files, or it'd be=20
> much easier just to let it get on with things.
>=20
> The basic read and navigation commands are all there -- see=20
> bin/bbackupquery/documentation.txt

 Another thing I miss: String-based listing.=20
 Something like this:

 --
 ls rc.*
 ls *.gif
 ls foo?.*.c
 --

 How about ftp's mget feature? Any possibility to include this?
 Or to make things better, implement recursive fetches from=20
 files/directories directly via 'get':

 --
 get -r remotedir/ localdir/
 get rc.* localdir/
 get -r foo/bar/* localdir/foo/bar/
 --

> >    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=20
 delete old log files to save more space. Then, 15 minutes after this,=20
 our boss asks for the last logs from the past 30 days. Oh!! it was=20
 deleted, so what? Cry?

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

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

> 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 =20
 automatically or not.

<snip>

> >  - Why have you chosen hex format by default?
>=20
> Constant width, compact representation, and clear display of byte=20
> boundaries, all very helpful when debugging.
>=20
> 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?

> >  - 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=20
> >  any size. This is not cool).
>=20
> Yes, this should be done. Sort of annoying for me too.

 I was almost certain you would agree with me ;-).

> >  - Wrap you source code/documentation in 72/80 columns. It's much
> >  more easy to deal with it.
>=20
> My screen is 1920 pixels wide :-) , and I have an editor which
> soft-wraps my documentation. This I think is explained by the history
> of the project -- things are done to make my life easy. Of course,
> this does not mean to say that I'm not going to make things easier for
> others eventually. This is a learning experience for me.
=20
 Okey dokey ;-). I run at 2048x768. I know what you mean.



 Best Regards,

 --=20
 Eduardo A. Alvarenga=20
 Analista de Suporte
 Centro Estrat=E9gico Integrado / SEGUP-PA
 (91) 259-0555 / 8116-0036

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (OpenBSD)

iD8DBQFAGYELpKK2uJoGDlMRArPxAJ9sI8HlqKMqkUqmbcvG8+WRawXa2ACeLV0l
rUxs7Ih0kPiSH3+8AuCEX4Q=3D
=3DHFro
-----END PGP SIGNATURE-----