Of all the times for S3 to go out.. it had to be while I was right in the middle of coding s3sync changes.

This is, by far, the most ironic definition of "high availability" that I have ever seen.

It's a good thing for AWS that they made the S3 API so well, or else I'd totally kick this crap to the curb and go with a competitor.

subject says it all

Well trivially speaking you could call it as a system command.

To do something more sophisticated would require bit of a refactor of the code.  Right now, the options setting, command-line parsing, and outer "main" execution are all sort of tightly coupled.  I had not ever envisioned making an API, per se.

It's a good idea though.

Does anyone know whether the "gem" distribution (see home page) solves this issue?  I've never tried it.

If so, then I guess it might be time for me to look into what's needed to distribute the main package as a gem.

Did you *upload* the files using s3sync.rb?  If so, then directory nodes should have been placed which would, upon retreival, do all the correct local dir creation.

Here is the patch I was sent by Benjamin Jackson.  I have been so busy that I literally haven't even looked at it yet.

You (anyone) are welcome to poke at it and let me know what you think.  I can't recommend or anti-recommend it yet.

See http://developer.amazonwebservices.com/connect/thread.jspa?messageID=52969&tstart=0#52969

subject says it all.

ruby -I /usr/local/s3sync /usr/local/s3sync.rb -r foobucket:barprefix /restore/dir

This says "put the item foobucket:barprefix into the /restore/dir " folder.  So it tries to recursively fill /restore/dir/foobucket:barprefix which

• doesn't exist, and
• is silly

s3sync expects there to be some part of the path in common (i.e. the 'prefix') after the s3 bucket name.  So paths of the form
foobucket:barpath
will work, but
foobucket:
will not.