I don't know any case where AWS issues 302's.  Are you using --ssl?  If not, maybe some proxy is trying to redirect you.

The default retry interval is 30 seconds, and 100 retries.  Both of these are changeable.

I have 7 sync targets, one per day of the week.  A script syncs to the appropriate prefix each day. 

Delimiter: /
tells S3 that we want to get a list only up to the next forward slash.  This makes the lists correlate with the local directory listings better.

Content-Length: 971
means that the item it is uploading is 971 bytes.

Delim and CL are not part of the error problem.  They are just part of the request headers of the req that failed.

If there was a problem regarding underscores, it should always occur.  If it works on retry, then it can't be a bug in sync.

I am not sure you can make a bucket public writeable.. can you?  Does the request work if you do just public-read?  Personally I use s3fox to poke at permissions after upload.  I probably should update s3cmd to have that type of feature.

Your bucket is "bucketname"?  Can you give greg13070 access so I can try to replicate the problem?  What env/yml values are you using (omitting your user id and secret password of course)

Get newer ruby?

Yes it should not be doing extra work, as you presume.

Include -d output.

Why should it upload again when they haven't changed?  It checks md5 and size first and skips stuff that is still equivalent.

They aren't errors, you probably have -v or -d on. 

Can you show me the sequence of commands you use and a test model of the directory structure that causes your issue?

Wonder if it has to do with the proxy feature added... What ruby ver?  Maybe there were incompatible changes made.

Well there is a problem. Your arguments are backward.  Putting s3 path first and local after means s3 -> local
Try switching the order.

One small wish that I'd make for 1.2.5 would be potentially to include the location of s3sync.rb in the places that s3sync uses to look for the config file.

Why not just ln -s it to one of the search paths then?  I won't make the config search too promiscuous because I can see some kind of vuln where the script is fooled to look at the wrong config, and sends your secret data to someone else.  This wasn't an issue prior to 1.2.4 since the script only ran correctly when you were standing in the s3sync dir.  Now that it can run "from anywhere" there are extra considerations to have!