[Box Backup] Boxbackup suggestions
Thu, 29 Jan 2004 18:54:17 -0300 (BRT)
-----BEGIN PGP SIGNED MESSAGE-----
On Thu, 29 Jan 2004, Ben Summers wrote:
> 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=20
> sourcing it would be a good plan.
> 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.
> 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.
> The basic read and navigation commands are all there -- see=20
Another thing I miss: String-based listing.=20
Something like this:
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:
> 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.
> > - Why have you chosen hex format by default?
> Constant width, compact representation, and clear display of byte=20
> boundaries, all very helpful when debugging.
> Also, fits in very nicely with my intended use of the system.
> 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).
> 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.
> 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.
Okey dokey ;-). I run at 2048x768. I know what you mean.
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)
-----END PGP SIGNATURE-----