But does that work for binary data? In my application I'm processing zipfiles and Java keystore files. My read of StringIO is that it works great for anything that can be directly represented as ASCII or Unicode, but it seems like a lot of overhead to base64 encode something so I can store it in memory.
On Tuesday, July 31, 2012 6:31:38 PM UTC-5, mr.meker wrote: > > You shouldn't need to save a file twice. You are doing extra disk IO when > you should keep it in RAM until it needs to hit the disk. This is what you > should use instead of writing the file to /tmp. > http://docs.python.org/library/stringio.html > > On Tue, Jul 31, 2012 at 3:27 PM, wgoulet <[email protected]> wrote: > >> Hi, >> >> I'm a relatively new Python and brand new Flask user, so please bear with >> me. >> >> I'm developing a webapp that requires that I permit users to upload files >> which are validated before I store them in their final location on the web >> server's local filesystem. To satisfy this requirement, I have defined >> helper methods that I use to create a temporary copy of a FileStorage >> object that is processed to determine if it is valid. Once this check >> passes, I then want to save the uploaded file in a permanent location. >> >> Here's an example subset of my code: >> >> def confirm(): >> amfile = request.files['zipfile'] >> if validate_file(amfile): >> >> amfile.save(os.path.join("/www/docs",secure_filename(amfile.filename)) >> >> def validate_file(infile): >> infile.save(os.path.join("/tmp",secure_filename(infile.filename)) >> # My validation code goes in here; I read the file in /tmp and return >> true or false depending on the results >> >> >> The problem I'm running into is that when I call the save() function on a >> FileStorage object twice in a row, the second save() function creates an >> empty copy of the file. In the code above, I have a valid copy of my file >> stored in /tmp, but the file in /www/docs is zero file size. I don't think >> that copying the file from /tmp to /www/docs is the right solution, because >> the validation code could potentially destroy or overwrite the temp copy >> (say if the file is a zip file as it is in my case) >> >> Looking at the source of FileStorage.save(), it looks like the reason for >> this behavior is that the shutil.copyfileobj function advances the >> filepointer when it copies from the source, but it doesn't move it back to >> the beginning of the file stream when it's finished (the copyfileobj docs >> state as much). >> >> As a simple test, I modified the FileStorage.save() function in my local >> werkzeug install to add a file seek call before the copyfileobj call as >> follows: >> >> from shutil import copyfileobj >> close_dst = False >> if isinstance(dst, basestring): >> dst = file(dst, 'wb') >> close_dst = True >> try: >> # Reset file pointer before copying from object >> self.stream.seek(0) >> copyfileobj(self.stream, dst, buffer_size) >> finally: >> if close_dst: >> dst.close() >> >> With this change, I can use the FileStorage.save() multiple times to save >> multiple copies of the FileStorage file. >> >> Would it make sense to modify FileStorage.save() as I've done here, or is >> there another, better way to achieve my goal? >> >> Thanks, >> Walter >> >> -- >> You received this message because you are subscribed to the Google Groups >> "pocoo-libs" group. >> To view this discussion on the web visit >> https://groups.google.com/d/msg/pocoo-libs/-/kH6rN1tQemoJ. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/pocoo-libs?hl=en. >> > > -- You received this message because you are subscribed to the Google Groups "pocoo-libs" group. To view this discussion on the web visit https://groups.google.com/d/msg/pocoo-libs/-/nvdvtklQ-A4J. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pocoo-libs?hl=en.
