I've been watching this folder ... C:\CFusionMX7\runtime\servers\coldfusion\SERVER-INF\temp\wwwroot-tmp
.... and I can see file uploads spooling there (you can hit F5 and see the file size increase). Does this mean that files uploaded spool directly to the HD or that there's a memory map thing going on? I don't know. What I do know is that if a file transfer gets cut off the temporary file remains there, stranded, and has to be manually deleted. Another problem. Yes, HTTP posts 10gb large may be ridiculous, but for this client I have to try to make it work. Switching out to SFTP with the service they have running is not going to be easy, or smooth. Got any ideas? I'm going to try the MX7 updater to see if that fixes anything. I see something about a file upload limit. So far MM has not replied back with what the maximum the number can be. I mean, can I set it to 10gb? Michael At 11:57 PM 12/6/2005, you wrote: > > To add, uploading a 300mb file does not mean that 300mb of > > RAM is used! If that was the case there would be no such > > things as enterprise CMS tool - "ooh I'm sorry you cannot > > upload an image to the CMS, someone else is.." > > > > A file is just uploaded by http/ftp - bit by bit. IIS does > > not hold it in memory per se. > >There are two problems with this analysis. First, most enterprise CMSs will >choke on 300 MB image file uploads. Second, IIS doesn't have anything to do >with this, as far as I can tell. CF integrates with IIS 5 through an ISAPI >filter and an ISAPI extension, and with IIS 6 through an ISAPI wildcard >extension. I'm not fully up on IIS 6 ISAPI, but with IIS 5 at least, a >filter processes the request before IIS does anything. The filter code is >entirely written by MM folks. > >So the real question is, does CF hold the entire HTTP POST request body in >memory before writing to disk, or does it create a memory-mapped file when >it receives a large enough POST. I don't know the answer to this question >offhand, but maybe someone else does. > > > It is not held in memory of the server - that would be > > utterly pointless and unworkable. > >I would argue that allowing HTTP POSTs of 300+ MB is utterly pointless and >unworkable, for what that's worth. > > > Look at it this way - I you download a file to your HD which > > is 1GB and you only have 500mb of RAM does your download fail? > > Of course not, it is not based on memory. > >You are relying on common sense, which is a big mistake. I wouldn't be at >all surprised if HTTP POSTs are stored in memory rather than in the >filesystem. Writing a program which handles different HTTP POSTs differently >is more difficult than writing one which works the same way no matter what. >Browsers, on the other hand, write every file they download to the >filesystem, so it makes sense that they would handle large file downloads >the same as small file downloads. But in any case, you shouldn't make >assumptions about this sort of stuff, because common sense rarely applies in >these cases. > >Dave Watts, CTO, Fig Leaf Software >http://www.figleaf.com/ > -------- Michael Muller Admin, MontagueMA.net Website Montague, MA 01351 cell (413) 320-5336 fax (518) 713-1569 skype: michaelBmuller email [EMAIL PROTECTED] http://www.MontagueMA.net Eschew Obfuscation ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Purchase Studio MX from House of Fusion, a Macromedia Authorized Affiliate and support the CF community. http://www.houseoffusion.com/banners/view.cfm?bannerid=50 Message: http://www.houseoffusion.com/lists.cfm/link=i:10:5756 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/10 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:10 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.10 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
