Bug 41574 - getMethod InputStream and OutputStream not closed if exception occurs
Summary: getMethod InputStream and OutputStream not closed if exception occurs
Status: RESOLVED FIXED
Alias: None
Product: Slide
Classification: Unclassified
Component: WebDAV client (show other bugs)
Version: 2.1
Hardware: All other
: P2 normal (vote)
Target Milestone: 2.2
Assignee: Slide Developer List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-02-08 15:18 UTC by Michael N. Christoff
Modified: 2007-02-10 14:00 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael N. Christoff 2007-02-08 15:18:06 UTC
If an exception is thrown between after the input and output streams inStream
and fos are opened, but before they are closed, then the streams will not be
closed.  This error won't blatantly manifest itself on *nix systems, but on
Windows systems, the file being read from by the FileInputStream will be locked
and users will be unable to edit it afterwards (until the Slide client based app
is closed).  There is also the issue of it being a resource leak.

The solution is to put the code that opens the streams in a try block and then
close them in a finally block ensuring they'll be closed even if there is an
exception.

This bug is related to Slide Client bug 40835 in that it's the same general type
of error in both cases.
( http://issues.apache.org/bugzilla/show_bug.cgi?id=40835 ).

FIX is below:

    /**
     * Execute the GET method for the given path.
     *
     * Fixed situation where an exception may cause the input and output
     * streams not to be closed.
     *
     * @param path the server relative path of the resource to get
     * @param file The local file.
     * @return true if the method is succeeded.
     * @exception HttpException
     * @exception IOException
     */
    public boolean getMethod(String path, File file)
        throws HttpException, IOException {

        setClient();
        GetMethod method = new GetMethod(URIUtil.encodePathQuery(path));

        generateTransactionHeader(method);
        int statusCode = client.executeMethod(method);

        setStatusCode(statusCode);

        // get the file only if status is any kind of OK
        if (statusCode >= 200 && statusCode < 300)
        {
            FileOutputStream fos = null;
            InputStream inStream = null;
            try {
                // Do a simple little loop to read the response back into the passed
                // file parameter.
                inStream = method.getResponseBodyAsStream();

                fos = new FileOutputStream(file);
                byte buffer[] = new byte[65535];
                int bytesRead;
                while ((bytesRead = inStream.read(buffer)) >= 0) {
                    fos.write(buffer, 0, bytesRead);
                }

                return true;
            
            } finally {
                if(fos != null)
                    fos.close();
                if(inStream != null)
                    inStream.close();
            }

        } else {
            return false;

        }
   }    


PS:
Sorry to those on the dev mailing list who have already gotten an email from me
regarding this.


Cheers!

Michael N. Christoff
dmx_dawg@hotmail.com
Comment 1 Michael N. Christoff 2007-02-08 15:23:36 UTC
Sorry, this bug should be renamed 

"getMethod InputStream and OutputStream not closed if exception occurs"

instead of "putMethod ..."

Also in the line where it says:

"This error won't blatantly manifest itself on *nix systems, but on
Windows systems, the file being read from by the FileInputStream ..."

that should be FileOutputStream.

-mike
Comment 2 Antoine Levy-Lambert 2007-02-10 14:00:09 UTC
Fix committed, thanks very much for your contribution. Antoine