A few thoughts about possible enhancements to consider.
1) When using gpg, s3cmd refuses to perform "sync", for the reasons
described in the faq. But "sync --skip-existing" could work just fine ? All
that is needed is to add to cmd_sync_* the same gpg-related code that is
present in e.g. cmd_object_put.
2) faq says:
> To ease some of the problems from previous point s3cmd could have a local
> cache mapping sizes and md5sums of the encrypted files to the original
> plaintext sizes and checksums. This is on my TODO list as well. Stay tuned
You may add one more vote to implement this :)
"Local cache", or rather additional per-tree dynamic config, could have some
more usages. E.g. paranoid^W security-conscious users would appreciate the
ability to encrypt not only file contents, but also the file names.
It could be done similarly to:
1) Files in the bucket would be named e.g. by consecutive integers
2) s3cmd would create /top/of/the/tree/to/be/synced/.s3cmd-sync-config file,
that would store (besides other useful things) the integer->"real file name" mapping
3) the encrypted copy of .s3cmd-sync-config would be stored in the bucket as
well (to be able to restore from backup).
The additional layer of indirection provided by integer->"real file name"
mapping could be used to implement other fun things, e.g. to store multiple copies
of the same file, from different moments of time. Imagine
s3cmd sync s3://... ~/empty_dir --modification_time_before="Dec 2010".