Forum OpenACS Q&A: File upload failures

Error writing content: resource temporarily unavailable
    while executing
"ns_conncptofp $fp"
    invoked from within
"if {![string match "POST" [ns_conn method]] ||  ![string 
match "*multipart/form-data*"  [string tolower $type]] } {
            
            # Return ordinary or no ..."
    invoked from within
"if ![info exists _ns_form] {
        set _ns_form ""
        set method [ns_conn method]
        set type [ns_set iget [ns_conn headers] content-type]
        
        ## MSIE redirecte ..."
    (procedure "ns_getform" line 4)
    invoked from within
"ns_getform"
    invoked from within
"if { [ns_getform] == "" } {
        if $error_if_not_found_p {
            uplevel { 
                ns_returnerror 500 "Missing form data"
                return
            }
        } else {
            return ..."
    (procedure "set_the_usual_form_variables" line 2)
    invoked from within
"set_the_usual_form_variables 0"

When I've seen that error come out of AOLserver, it has been the result of a broken connection while downloading something big, a connection where presumably the user has become bored and moved on.  That would fit with your second scenario, where the form is resubmitted while the upload is in progress.  I can't imagine anyway to prevent that without using JavaScript to disable the form submit.

And that's seems to be what ns_conncptofp is complaining of too, that it was trying to copy the content from the connection to a file pointer when the resource went away.  Presumably the resource in question is the connection and not the disk.  To look into this further, you can start looking at nsd/conn.c/ConnCopy.  That routine has two error returns, one after the read, and one after the write.

The read usually does a nonblocking read from the socket, and if I recall, retrying twice after receiving an EWOULDBLOCK (and then waiting a configurable amount of time), and then finally give up. (but I'm not sure about all this.)  So if your conn goes away for more than the timeout period but is coming back, presumably you've got a pretty flaky connection to begin with.

My question, if you don't click submit again, do you still have the problem while uploading?

Cheers

However, if I apply this trick to file uploads by writing 300 characters before doing set_the_usual_form_variables, IE displays the new page only about halfway through the upload process. That still gives users plenty of time to click Submit again. Anyone know why this latency occurs?

Perhaps, using javascript to throw up a message box that says "wait" is the only idiot-proof solution???

Carl Coryell-Martin, I sure would like to have that robust uploading module!