SharpDevelop Community

Get your problems solved!
Welcome to SharpDevelop Community Sign in | Join | Help
in Search

Double gzip footers

Last post 05-11-2008 10:04 PM by JohnReilly. 2 replies.
Page 1 of 1 (3 items)
Sort Posts: Previous Next
  • 04-07-2008 2:28 AM

    • ghell
    • Not Ranked
    • Joined on 03-31-2006
    • Posts 4

    Double gzip footers

    In my opinion the following are bugs but whenever I file bugs for systems in their bug trackers, I get brushed off with a response similar to "this ridiculous behaviour was intended and is not a bug. We are not going to tell you why we chose to do it in this crazy way that makes no sense.", so I'd like to see what other people think of these "bugs".


    If you manually call Finish() and then later the GZipOutputStream is disposed, it adds another footer upon disposing. This doesn't stop most things from decompressing the resulting file without any problems so it is not obvious unless you inspect the file. Either way, the footer should only be added once. Here is an example of a double footer:

    using(GZipOutputStream outStream = ...)
    {
      ...
      outStream.Finish();
    }

    My suggestion is a simple check to see if the footer has already been written before writing it again. Another alternative would be to deprecate Finish in favour of Close (if it is called by Close anyway and Close is called by Dispose anyway) but this would mean that the stream would be closed whenever the footer is written which may not be what the author wants in some rare cases (for example seeking back in the stream and decompressing, as is used in the GZipTests class), unless the underlying stream is not closed when the GZipOutputStream is closed.

     

    Another problem is that you cannot Dispose a GZipOutputStream if it has already been Closed.  For example, the following will throw an exception:

    using(GZipOutputStream outStream = ...)
    {
      ...
      outStream.Close();
    }

     

    This is not a problem on the BZipOutputStream or any of the Streams in the .net API. The thing that makes me think it is a bug is that it is only this stream that exhibits this behaviour. My suggestion here is to not try to close the stream if it is already closed when disposing. Rather than throwing an exception that says it is already closed, just skip the redundant call to Close. If it is already closed when we are trying to close it, it doesn't matter anyway.

     

    It is possible that the Close problem also brings about the double footer problem if you ignore the exception, as a footer is added on the Close call and again on the Dispose, which calls Close. The only way that this wouldn't add the double footer is if the exception being thrown stops the footer from being added, but I suspect the footer is added before the attempt to close is made or it wouldn't be able to add it in the first place.

  • 05-11-2008 9:08 PM In reply to

    Re: Double gzip footers

    In my opinion they are bugs as well.

  • 05-11-2008 10:04 PM In reply to

    Re: Double gzip footers

    In a rare moment of coding I have changed the library to remove these loopholes, and added tests.

     

Page 1 of 1 (3 items)
Powered by Community Server (Commercial Edition), by Telligent Systems
Don't contact us via this (fleischfalle@alphasierrapapa.com) email address.