OK I've not seen that exact error, but one thing I notice is that you're trying to sync a single file .. which I think still has some problems.  The local argument should be a directory for best results.  You can put a trailing slash to indicate only files *in* that directory, but I don't think a bare file argument works.

Having said that, if that doesn't fix the problem then let me know (along with new command line and updated error message, if any)

Keep complaining (to aws).  This needs fixing!!

I don't habeeb it.  It seems like your ruby libs are something pre 1.8.4

It could be made to work I think 

Um about download resume, I don't remember for sure but I "could have sworn" that was supported.  Maybe I'm just out of my mind.

Etags come down in a list.. why would you have to head the items too?

Yeah so, let's assume those kinds of things are inevitable.  *Other* protocols that claim to support large uploads have some method to mitigate this problem built in.  S3 though, says "hey we support this" but doesn't provide any tangible way to do it.  That's not a feature imo.

Just check the etag.. the contents of the folders are always the same, so they will md5 to the same etag.  That's how *I* check what ones are folders.  I do that because the etag comes down in the item list and I don't have to head or get each node to check what it is.

And it goes without saying that tacking on some crap to the name is not a good solution.

As for cross compatibility, I can't say that I care really.  But the code is out there, so anyone can modify it, and post it up on the wiki.  In fact if it's a classy enough mod (with an option switch or something) I could even roll it in to the source.

But once again, I'm not changing the way it works by default, because my way is best.  Nyah. 

Can you reproduce this issue with a small set of dirs/files, and then archive them up and attach that here so I can test it on my system?  It sounds like this might be some kind of obscure comparator bug.  If so, that will be hard to diagnose remotely.

Well for example if you get 500 responses or some other non network-looking hiccup, it's easy to tell that it's on their side.

My larger point is that they don't provide any reliable way to do large uploads.  Resume, or some other solution, should be supported.

Well .. you could always create a patch 

If you're upset about AWS charging you for failed uploads, why not complain to them?  If they add the ability to do resume, or some other form of modifying existing objects, I will jump on it as fast as all the other devs I'm sure!

The problem, as I see it, is that s3 offers this theoretical feature of large objects, but they have two enormous practical problems with it.

• The +2GB upload bug
• The fact that there's no reliable way to send a large object to them

I could break the 'sync' paradigm to make an ugly patch on these problems.  But I won't.

Short answer: sorry, no.

As I mentioned before I'm not going to turn s3cmd into s3sync.  They are for fundamentally different things.  You still don't understand that S3 does not have a concept files and directories.  It just has nodes.  The concept of files and directories is added differently by each kind of tool.

s3sync makes directory nodes in exactly the way mentioned from the thread you linked.. It is a node containing meta data flagging it as a directory.  And those are the things that your 'firefox s3 organizer' are seeing as files.  So with s3sync I have already done this thing that you think you want.

I don't know about firefox s3 organizer or how (or if) it has some node format that it would interpret as an empty directory.  I have very good design reasons for doing directories the way I've done them and so it's not likely to change. 

As I have stated before, the only compatibility goal of s3sync is to make web browser operations on public nodes work as transparently as possible.  Now: If someone else wants to make an s3 shell that is interoperable with "firefox s3 explorer" and contains more types of operations and features that you would like, then they are welcome to do so.  They can even start by using my code if it helps.. it's a free license.  But I'm not going to build that tool myself because I don't have any use for it. 

/usr/lib/ruby/1.8/openssl/buffering.rb:178:in `syswrite': Connection timed out (Errno::ETIMEDOUT)
   from /usr/lib/ruby/1.8/openssl/buffering.rb:178:in `do_write'
   from /usr/lib/ruby/1.8/openssl/buffering.rb:192:in `write'
   from /usr/lib/ruby/1.8/net/protocol.rb:175:in `write0'
   from /usr/lib/ruby/1.8/net/protocol.rb:151:in `write'
   from /usr/lib/ruby/1.8/net/protocol.rb:166:in `writing'
   from /usr/lib/ruby/1.8/net/protocol.rb:150:in `write'
   from /usr/lib/ruby/1.8/net/http.rb:1571:in `write_header'
   from /usr/lib/ruby/1.8/net/http.rb:1526:in `exec'
   from /usr/lib/ruby/1.8/net/http.rb:1045:in `_HTTPStremaing_request'
   from ./HTTPStreaming.rb:45:in `request'
   from ./S3_s3sync_mod.rb:52:in `make_request'
   from ./S3.rb:175:in `delete'
   from ./s3try.rb:51:in `send'
   from ./s3try.rb:51:in `S3try'
   from ./s3sync.rb:463:in `delete'
   from ./s3sync.rb:339:in `main'
   from ./s3sync.rb:639

This topic has been moved to General Discussion.

http://s3sync.net/forum/index.php?topic=36.0

That's vestigial code and isn't used by either of the programs.

This is the secret (sshhh don't tell) to why I like to foster the s3sync community and don't overtly ask anything in return.  It is really hard to catch all my own bugs