From: Thomas S. <tho...@gm...> - 2009-02-10 17:09:25
|
Hi, The problem occurs when trying to upload files with UTF-8 characters in them. So far I've resorted to cheezy solutions in hope that my distrubtion simply included an update that fixed it at some point. :) But I can't do that anymore. My first attempt was to try new versions. Results for each versions as follows: * 0.9.8.3 - Debian Testing repository Here I get > "WARNING: MD5 Sums don't match!" for the offending files. Upload of the offending file fails, but the script continues. * 0.9.8.4 from Debian Experimental repository Here I get > "UnicodeDecodeError: 'ascii' codec can't decode byte 0xe5 in position 2: ordinal not in range(128)" for the first offending file, and the script stops here. * 0.9.9-pre5 from tarball Here it hangs for a few minutes on each file, and yields the following warning for each file: > WARNING: Upload failed: /srv/archive/archive/git/cl-aoc-chat/packet.lisp () > WARNING: Waiting 3 sec... This has nothing to do with UTF-8, I guess. I'm not sure if something changed in the config file or the syntax of the command, but I'm not getting any warnings about it. ---- Dimitrios Kordas has reported the exact same problem I had with 0.9.8.4 here: > http://www.mail-archive.com/s3t...@li.../msg00050.html I have LANG=en.UTF8 in my environment. The set of offending characters in my filenames are æ, ø, å, Æ, Ø and Å. Any ideas appreciated. Regards, Thomas |
From: Michal L. <mi...@lo...> - 2009-02-11 02:52:28
|
Thomas Stenhaug wrote: > * 0.9.9-pre5 from tarball > > Here it hangs for a few minutes on each file, and yields the following > warning for each file: > >> WARNING: Upload failed: /srv/archive/archive/git/cl-aoc-chat/packet.lisp () >> WARNING: Waiting 3 sec... Is this reproducible? It looks like a temporary connection problems to me. If it is reproducible can you run s3cmd with --debug and send me the output? Are you using GPG (--encrypt) by the way? > This has nothing to do with UTF-8, I guess. I'm not sure if something > changed in the config file or the syntax of the command, but I'm not > getting any warnings about it. Nope, there shouldn't be anything like that. The only important entries in ~/.s3cmd are the access key and secret key and eventually GPG encryption key. The rest can be removed and defaults will be used. Michal |
From: Thomas S. <ka...@gm...> - 2009-02-11 15:44:38
|
On Wed, Feb 11, 2009 at 3:52 AM, Michal Ludvig <mi...@lo...> wrote: >>> WARNING: Upload failed: /srv/archive/archive/git/cl-aoc-chat/packet.lisp () >>> WARNING: Waiting 3 sec... > > Is this reproducible? The behaviour was consistent, yes, tried several times over several days. The failing command originated from a backup-script of mine. When I alternated between 0.9.8.4 and 0.9.9pre5, the former would always complete (albeit with the UTF-8 problems), and 0.9.9pre5 would always fail. I played around a bit with 0.9.9pre5. First I deleted the configuration, ran "s3cmd --configure", created a new bucket, and played around with "simple" command on it. Everything works. I'm currently running a sync into that bucket. I'm a few hundred files in, and so far there haven't been any hickups. (Except for some unrelated, unexpected behaviour, I'll get back to that.) No files with UTF-8 in the filenames have been synced yet, though. I will follow up later if I run into the same problem with this new setup. > It looks like a temporary connection problems to > me. If it is reproducible can you run s3cmd with --debug and send me the > output? I've changed a lot of things now, but I'll try to recreate the state where this happened. If I can, I will report in a new mail. > Are you using GPG (--encrypt) by the way? This was with they "sync" command, so, no. >> This has nothing to do with UTF-8, I guess. I'm not sure if something >> changed in the config file or the syntax of the command, but I'm not >> getting any warnings about it. > > Nope, there shouldn't be anything like that. The only important entries > in ~/.s3cmd are the access key and secret key and eventually GPG > encryption key. The rest can be removed and defaults will be used. This seems to be correct, Using 0.9.9pre5, I have alternated between my old .s3cfg, and the fresh one created with "s3cmd --configure" without any related change in behaviour. Two unrelated things: unexpted behaviour of the "del" command in both versions, and a change in semands of the arguments to the "sync commands." When I run the "del" command on a url that has children, it says "object deleted", but there is no visible change (ie, the directory object still exists, with all it's children.) I expected either the entire directory to be gone, or getting an error informing that all child-objects have to be deleted first. (I'm now aware that "del --recursive" does what I want, but the behaviour of a bare "del" is still confusing.) Next, When I do "s3cmd sync /dir1/dir2 s3://bucket/dir1/dir2", 0.9.8.4, the resulting structur is "s3://bucket/dir1/dir2/" With the 0.9.9pre5, the resulting structure is "s3://bucket/dir1/dir2/". When I change to "s3cmd sync /dir1/dir2 s3://bucket/dir1" using 0.9.9pre5 I get the "old" behaviour. |