Please do.  This is something I've thought about doing myself but haven't yet; mostly because I wanted to try and do some kind of timestamp check to make up for it (which is non-trivial to accomplish)

http://s3sync.net/forum/index.php?topic=67.msg258#msg258

Added Alastair Brunton's yaml config code.

Drop me an email (see the readme for the address) and send your changes.  I'll be happy to take a look!

I've got no idea.  How could the same software work on one of your machines and fail on the other?  Different ruby library versions maybe?

If you use -s are the results different?  If so, you're being proxied.  If not, your credentials are wrong.  403 results can't be generated from within the client, so (unless some spontaneous bug emerged in the un-changed code) it's got to either be something upstream of you, or something in your credentials.

All my boxes are debians and it seems fine.  Though you need something newer than sarge.

Your ruby version is too old; see README

I can't tell you specifics about your other tool because I haven't used it.

1.1.2 and earlier had a bug where the top level directory node, in certain cases, was made with a trailing slash in the name.  This is fixed in 1.1.3.

If you want to interop with s3sync, then the tool should store directory nodes in a compatible fashion (unlikely, since no one else has realized how cool it is to do it the way I do)

Alternately, you could write a patch for s3sync that makes it work the way you want.  Beware though.. slash parsing semantics is A BEAR.

It's a simple request but it opens a can of nightmare 

I think it means that if you use a domain with a CNAME pointing to s3.amazonaws.com then request signing works.  I haven't personally tested anything like that.

s3sync tools don't care about size of things, so the answer to the second thing is "no".

Oops I forgot to update the version number in the s3sync.rb file.  Done.

Notice too that the new release puts its files in a subdir (unlike previous ones)

And in case it was not clear from the release notes:
In order to "fix" this, you would have to re-sync from local sources to s3 targets.  The problem was in that aspect, not in the retrieval.  So if you were just trying to test by re-downloading your bucket, the thing would still appear broken.

I have no idea.. never seen this nor been able to reproduce it.

If you can come up with circumstances that I can test, then let me know.

You could try running with -d to see if it's doing something in that time; but it doesn't sound like it.

Based on how old this ticket is, I assume you're probably not watching this any more or using s3sync.  But let me know if I can help.

the NoMethodError stuff should be fixed in 1.1.3

fixed in 1.1.3