On Jan 21, 2008 3:36 PM, Edi Weitz edi@agharta.de wrote:
No, it's the first time I hear of it. How do you make the distinction between "binary" and "text" files? Hunchentoot doesn't do that, it treats every upload as a binary file. And what do you mean with
I uploaded a lisp source file and an image file (in separate form submits.) Diff tells me that the source and uploaded text files are the same, but the source binary file (a .png) is 81487 bytes, while the uploaded binary file is 120258 bytes. So the uploaded file is longer, not truncated. I used the same browser (Safari) on the same machine to upload to both the Linux Hunchentoot test server (SBCL) and the OSX one.
"corrupted"? Is the uploaded file shorter than the original or longer or is it the same length but wrong data? Is this reproducible or does it only happen sometimes? Have you checked that this is not a browser issue? (You could try uploading from Drakma, for example.) Did you see something in Hunchentoot's log file? Are you really sure you removed /all/ FASL files after updating? Do you have a chance to test with OpenMCL on Linux instead of OS X?
Tried also with Firefox and saw the same problem. The problem is reproducible 100% of the time. I didn't see anything in the log files except for the normal POST notice.
Oh, I've found the problem. I had the following settings in my .emacs file:
; (set-language-environment "UTF-8") (setq slime-net-coding-system 'utf-8-unix)
Months ago I had commented out the first line while trying to track down a crash in OpenMCL and forgot to uncomment it later. Anyway, with both lines either enabled or both commented out, uploading works correctly.
Sorry for the false alarm.
- Peter