initial commit



git-svn-id: http://brackup.googlecode.com/svn/trunk@1 c3152786-d43a-0410-8499-09eb43983aed
get gnupg kinda working

git-svn-id: http://brackup.googlecode.com/svn/trunk@2 c3152786-d43a-0410-8499-09eb43983aed
Changes regarding this:
   http://brad.livejournal.com/2206367.html

For posterity,

GPG "salts" (or whatever it's called) encrypted files, so if you encrypt a file multiple times using the same public key, the resultant encrypted file is always different.

For my purposes, this is a pain. Is there a way to disable it? I probably shouldn't, but I'm just curious. I realize if I disable it, it's possible for others to prove the existence of a file on my machine, if they have my public key (easy), and the original file they want to check for.

So yes, I really want to keep it enabled, but I didn't plan for it, and now I have to go back and re-design a bit.

I wanted to keep my digest caches as simply caches, with no harm but extra network latency and CPU if the digest cache is lost, but now I need to factor in the face that losing the local machine's digest cache will cause extra allocation of chunks on the server (because new encrypted file differs), which you pay for (for disk usage).

Which implies I need to store the digest cache on the server as well. Encrypted.

But that doesn't scale, since it'll only get bigger with time, and the uploads will suck more and more each day, not proportional to changed files.

Which implies storing iterative/delta digest caches, and having like a digest cache master index that lists all the digest caches on the server. But then there are race conditions if multiple backups are running.

Or I could just rely on the storage target to support enumeration of like objects. Like, "give me all digest cache files", but that removes the ability of a storage target to be purely key-value. So for the Filesystem, FTP, Scp, Amazon targets, this is no problem, but it might be a problem for other targets? MogileFS? well, mogile at least lets you enumerate keys by prefix, so I guess it's possible, if you design for it.

Okay, so that's fine. I'll go with that.

But I'm just annoyed that I have to go implement it all now.

Fuck all this: I just rename the "Digest Cache" to the "Digest Database" and make it required, documenting that you can't delete it. Just store it on the same filesystem as the files you're backing up. If you lose it, well... you probably lost all your other files anyway and need to restore. Okay, the show (er, hacking) goes on.... s/cache/database/.






git-svn-id: http://brackup.googlecode.com/svn/trunk@3 c3152786-d43a-0410-8499-09eb43983aed
some docs

git-svn-id: http://brackup.googlecode.com/svn/trunk@4 c3152786-d43a-0410-8499-09eb43983aed
include original link

git-svn-id: http://brackup.googlecode.com/svn/trunk@5 c3152786-d43a-0410-8499-09eb43983aed
tech notes

git-svn-id: http://brackup.googlecode.com/svn/trunk@6 c3152786-d43a-0410-8499-09eb43983aed
more docs, and s/cache/digdb/ in File.pm

git-svn-id: http://brackup.googlecode.com/svn/trunk@7 c3152786-d43a-0410-8499-09eb43983aed
work for the night.  works, but no metafile written yet.

added docs on thoughts.




git-svn-id: http://brackup.googlecode.com/svn/trunk@8 c3152786-d43a-0410-8499-09eb43983aed
change data structures a bit.  make the chunk keys based on sha1 of
file, not the file's cachekey, because we have to support moving files
between filesystems and inode changing...  all inodes changing with
contents not changing should penalize you is having to recompute the
sha1 of orig, not recomputing all the encrypted chunks



git-svn-id: http://brackup.googlecode.com/svn/trunk@9 c3152786-d43a-0410-8499-09eb43983aed
can write the .brackup rfc822 metafile now.

with docs!

can't configure where it goes, though, and can't restore.




git-svn-id: http://brackup.googlecode.com/svn/trunk@10 c3152786-d43a-0410-8499-09eb43983aed
let you specify output file

git-svn-id: http://brackup.googlecode.com/svn/trunk@11 c3152786-d43a-0410-8499-09eb43983aed
functional now, but no restore.

and verbosity is cranked way up.



git-svn-id: http://brackup.googlecode.com/svn/trunk@12 c3152786-d43a-0410-8499-09eb43983aed
cleanup

git-svn-id: http://brackup.googlecode.com/svn/trunk@13 c3152786-d43a-0410-8499-09eb43983aed
make Amazon target kinda work.  Net::Amazon::S3 is still buggy, as is
maybe S3.




git-svn-id: http://brackup.googlecode.com/svn/trunk@14 c3152786-d43a-0410-8499-09eb43983aed
don't backup the digest database

git-svn-id: http://brackup.googlecode.com/svn/trunk@15 c3152786-d43a-0410-8499-09eb43983aed
a --help mode, and docs

git-svn-id: http://brackup.googlecode.com/svn/trunk@16 c3152786-d43a-0410-8499-09eb43983aed
make a starter template for them

git-svn-id: http://brackup.googlecode.com/svn/trunk@17 c3152786-d43a-0410-8499-09eb43983aed
packaging

git-svn-id: http://brackup.googlecode.com/svn/trunk@18 c3152786-d43a-0410-8499-09eb43983aed
more packaging

git-svn-id: http://brackup.googlecode.com/svn/trunk@19 c3152786-d43a-0410-8499-09eb43983aed
add no warranty statement

git-svn-id: http://brackup.googlecode.com/svn/trunk@20 c3152786-d43a-0410-8499-09eb43983aed