You'd have to set up profiling in ruby to see where the cpu is going.  I bet it's not in the s3sync code; the ruby http library is awful.

It might not be perfect.  Try creating the top level directory it's stuck on.

I just used patience

Yeah that's a good reason, I was just wondering.  I've never run through cygwin, but it seems like the bug is in cygwin or the ruby library (because the uid/gid code in s3sync is dead simple). 

Just a thought... but why run s3sync in cygwin with busted permissions when you could just run it native in windows where uid/gid and such are ignored?

I'd guess the cpu is due to s3sync md5'ing every local file to check if it needs to be re-sync'd.  But just a best guess.  Otherwise, it's not really meaningful to compare the two.  They don't share any common code or architecture.

Yes with "--delete" you are instructing it to do the thing that you don't want.  There is also no need to use -d unless you are debugging.

To s3, nothing direct.  They just set values that will be returned when something does a GET for that item.  Exp and CC are used by browsers and proxies to determine how (long) to cache a resource.

I think the latest revision fixes the SSL retry fail-loop.

I haven't looked at that stuff but yes s3sync/cmd uses REST.  One *can* do signed URLs in s3cmd but it is not the default.

But really, I have almost no concept of Devpay so I can't comment on compatibility beyond that.

I still call it a bug, but this helps explain why it hasn't been caught for so long.

Sure seems like a bug.. Instead of test and test2 what if you use "test" and "apple" or something that doesn't begin with the other one.  It shouldn't matter but I wonder if the S3 listing logic is returning like all of "test*" when we expect "test/*"

Let me know if that makes a diff.  As it may be apparent, I haven't had any time for this project lately ......

Try with another app to confirm it's not a config issue.  Try with SSL, maybe you are being proxied.  If that fails, then I'd blame the id/secret next.  If that fails, check if you paid your S3 bill?

If you can wireshark or tcpdump the non-ssl transaction (whole packets not just the useless headers) you may be able to see a more detailed error in the response.

Here you go:
http://code.google.com/p/s3sync-s3cmd/source/checkout

As I get more time I'll start offloading items from this site over to google.

Understood.  I have been asked to just put this up on google code instead of having this hacked-together custom site for it. It's a great idea but I've been too busy to do so yet.