8 Replies Latest reply on Feb 2, 2007 3:28 PM by justpicksomething

    File I/O Error - Error #2038

    Kristian Wright Level 1
      I've seen a few posts on this error but none of them seem to solve my

      I'm trying to upload some files via a FileReference object, with a CF
      backend. The CFC works fine with smaller files (eg under 300k), but
      with files over this size, sometimes it works, sometimes it doesn't.

      When it doesn't work, I get the following I/O Error:

      text="Error #2038: File I/O Error.
      URL: my URL

      The server side script is working, as I can try and upload a smaller
      file, and it works. But when I'm getting the I/O error, the app stops
      before it even reaches the CFC. I've set a Progress listener to the
      FileUpload object, and it seems to just slow down and eventually stop,
      throwing the I/O error before file upload has reacherd the total bytes
      of the file.

      Does anyone know what might be going on here?

        • 2. File I/O Error - Error #2038
          jpwrunyan Level 1
          That is the most unhelpful error message (perhaps) in the world--not that it's your fault or anything.
          I am getting an I/O error (#2032) with HTTPService doing an entirely different thing....

          Here are my thoughts:
          Are you perhaps testing using a proxy?
          Are you maybe using relative paths instead of absolute?

          if yes, that might have something to do with it.
          • 3. Re: File I/O Error - Error #2038
            Kristian Wright Level 1
            No, not testing using a proxy and I am using an absolute path.......
            • 4. Re: File I/O Error - Error #2038
              jpwrunyan Level 1
              My only other thought is if you are testing via the localhost with a live server, or if you are testing by running the html in your browser locally. Sometimes my web-service related objects throw errors if they are not accessed via an actual application server (http:localhost//myApp.html vs c:\project\myApp.html). It's hard to believe you'd have gotten this far, though, if you weren't already testing via a web application server....

              Otherwise, I hate to say it, but it might be a problem with your server app and not the flash player/flex application .swf. Maybe see if you can make a server side script that will show you the actual form data being sent from the application--without any sort of processing. As long as you are getting that, then the .swf is doing all that is asked of it.
              • 5. Re: File I/O Error - Error #2038
                schjlatah Level 1
                I am getting a similar error (HTTPService error #2032) when trying to consume a WebService. I have multiple calls to the same webservice. One works, the other throws an error. I love flex, I hate the vagueness of the error messages. Also is there a master reference for all six of their error codes? Does it say #1002 = this #2032 = this?
                • 6. Re: File I/O Error - Error #2038
                  aerospc04 Level 1
                  2 Bugs exist in IE that my throw a 2032 error...

                  IE + HTTPS + XML + No Cache
                  IE + GZIP Compression (via server)

                  To resolve the first problem...
                  header('Cache-Control: cache, must-revalidate');
                  header('Pragma: public');

                  See http://www.dirtystylus.com/blog/?p=17 for more info

                  Hope this helps
                  • 7. Re: File I/O Error - Error #2038
                    __Voodoo__Child__ Level 1

                    Here is the list of runtime errors

                    Gotta love the 2032 documentation.

                    • 8. Re: File I/O Error - Error #2038
                      justpicksomething Level 1
                      from a yahoo group that is a little more on the ballthan this lame forum:
                      > >
                      > > Here is what doesn't work seamlessly:
                      > >
                      > > 1. HTTP AUTH - Authorization Headers will corrupt data exchange. If
                      > you
                      > > upload to an application running within an authorized HTTP session,
                      > in some
                      > > browsers the upload will fail. I have seen this occur in Safari(OSX)
                      > and
                      > > FireFox(Win32).
                      > >
                      > > 2. POST Parameters will corrupt data exchange on an Upload request.
                      > This is
                      > > specific to FireFox(Win32) when additional HTTP POST parameters are
                      > added
                      > > into a request. I have seen this occur in Safari(OSX) and
                      > FireFox(Win32).
                      > >
                      > > 3. HTTPS/SSL usage with FileReference requires a separate loading of a
                      > > crossdomain policy file for use within the same domain.
                      > >
                      > > The FileReference functionality in FireFox(Win32) does not use the
                      > FireFox
                      > > browser to exchange data, instead it uses native Win32 networking. I
                      > believe
                      > > that many of the errors in Firefox are a result of upload and download
                      > > requests traveling through win32 networking. When using Authorization
                      > > headers, you will see the Internet Explorer Authorization Security
                      > Dialog
                      > > appear in addition to the Firefox Authorization Security Dialog. The
                      > problem
                      > > is that authorization headers are not shared between Firefox and Win32
                      > > Networking. Although you may have Auth session headers in Firefox,
                      > when you
                      > > use upload/download, the header data is lost.
                      > >
                      > > Ideally I have found that it is best to use very simple upload logic
                      > for
                      > > compatibility. I typically use URLRewriting to add parameters into the
                      > > upload url path without the use of GET/POST parameters. I upload to a
                      > > separate HTTP/HTTPS subdomain and pass a unique token within the
                      > upload
                      > > request url like so:
                      > >
                      > > http://upload.myserver.com/upload/29879827342342342
                      > < http://upload.myserver.com/upload/29879827342342342>
                      > >
                      > > The upload application saves the upload file data if the token
                      > exists and
                      > > expires the token when an upload occurs or within 10 minutes. This
                      > > methodology seems to work compatibly for all existing browsers and
                      > can be
                      > > adapted to any security model.
                      > >
                      > > On the download requests URLRewriting is also very handy. To make
                      > sure the
                      > > filename is returned consistently, I append the name into a
                      > URLRewritten
                      > > request like so:
                      > >
                      > > http://upload.myserver.com/upload/2020938409987234/myFile.pdf
                      > < http://upload.myserver.com/upload/2020938409987234/myFile.pdf>
                      > >
                      > > In this case, 2020938409987234 is used to obtain a file but the name
                      > makes
                      > > sure that the user will always be presented with 'myFile.pdf' within
                      > the
                      > > FileReference SaveAs Dialog. I have seen several cases where the
                      > > defaultFileName argument on the download method will fail when POST
                      > or GET
                      > > Parameters are in use. If you call download with the above URL, the
                      > name
                      > > will be myFile.pdf consistently.
                      > >
                      > > Please understand that these solutions are not ideal but they work
                      > well and
                      > > I have yet to find a case that could not be adapted into an
                      > application.
                      > >