Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Files (stl/gcode) corrupted on upload #680
I was having a problem with binary STL files not wanting to be sliced by Slic3r because "File size mismatch". I looked at the uploaded STL file and sure enough it had two extra bytes on the end of it
I started digging in and all files which I've uploaded using the relatively new "temp upload file rename" tornado server code have extra
I tracked this down to
The code in the tornado handler looks for the boundary and splits the data off properly but doesn't remove the newline at the end. The file will contain the delimiter which is actually the start of the mime boundary. The simple fix is this
But you need to make sure that the request bodies are being rebuilt properly for other multipart types (which I believe have extra
It looks like there is some information missing from your ticket that will be needed in order to process it properly. Please take a look at the Contribution Guidelines and the page How to file a bug report on the project wiki, which will tell you exactly what your ticket has to contain in order to be processable.
If you did not intend to report a bug, please take special note of the title format to use as described in the Contribution Guidelines.
I'm marking this one now as needing some more information. Please understand that if you do not provide that information within the next two weeks (until 2014-12-29 15:30) I'll close this ticket so it doesn't clutter the bug tracker.
PS: I'm just an automated script, not a human being.
I love cookies. I truly do.
I do remember! I never would have found that bug. This is wicked straight-forward as far as reproducing goes. Just hexdump a file before upload and after and you'll see it has the extra \r\n on it.
It makes sense looking at the code too, it reads everything to the mime barrier but it is always preceded by \r\n which the code doesn't remove so whatever the German equivalent of "Bob's your uncle" is. I was just concerned about the rebuilding of the message now without the extra line delimiters maybe affecting other code where you've come to expect it there. I've been using it all week and have played around changing settings (which would also be POSTed right?) and it all seems to be ok. You know your internals better than I do though. Sometimes I can't figure out how some bit of code magically runs out of nowhere by design. Because: FUS RO...CTOPRINT!
There was still an issue when writing the body back in case of file uploads which caused the included form parameters to not be written out correctly (because here suddenly a
So big thanks for spotting this! Now the md5sums of uploaded files match their original ones too :D