The temporary folders were not removed.

Same errors in my d5 installation.

OK, just committed a fix which removes the temporary folder when a broken archive is detected. Any other case when the temporary folder is not removed?

The tmp folder is not removed when the script execution time exceeds. I can't configure it on my hoster :( I have to test in my local installation.

Well, well, removing the temp folder when PHP times out is pretty impossible, as when PHP times out, we cannot do anything anymore. It is timed out. The check for the existing temp folder throwing an error (instead of removing the temp folder and recreating) is there to protect parallel processes running, eg. you run scanning in more browser windows. Of course we could do multiple temp folders with (in part) random names, regularly cleaning up old folders, so the scanner can run even if there was a timeout or some other error, which made it impossible to clean up, and this would even allow parallel processing. I'll look into how this can be implemented later.

Not sure if same problem, but http://drupal.org/node/201698 looks like the same... but i can assure my PHP does not timeout.

This was mostly solved by the "Merry Christmas" update I just committed. It is a *huge* UI change, so do not update without thinking it through. The reason I say it is mostly solved is that the new code uses different temp folders each time, so you will not notice any problem when the next parser starts. When PHP times out in the parsing phase, some folders might be left over in the temp folder, but that's all. Otherwise l10n_server will work fine. A cron based old folder removal might be implemented to overcome this though.

Not yet solved on my Windows box. I looked inside the temp directory and the temp directories are staying there after a scan without timeout.

24.12.2007  18:20    <DIR>          l10D8D.tmp_dir
24.12.2007  18:21    <DIR>          l10D8E.tmp_dir
24.12.2007  18:21    <DIR>          l10D8F.tmp_dir
24.12.2007  18:21    <DIR>          l10D90.tmp_dir

6.x-dev version? :-)

Looks like this was not reproduced anymore.