Home Forums .NET libraries Xceed Zip & Real-Time Zip for .NET ZippedFile.OpenRead(password) is returning error

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • User (Old forums)
    Member
    Post count: 23064
    #20345 |

    I have instantiated a zippedfile object to a known file within an archive.

    Dim zipfile As DiskFile = New DiskFile(MyZipFile)

    Dim testzip As New ZippedFile(zipfile, Path.GetFileName(ENCRYPTION_TEST_FILE))

    I know the object is created properly as the Exists and the Encrypted properties are available:

     If testzip.Exists Then
                If testzip.Encrypted = True Then

    But – when I try to use OpenRead it throws an exception…

                      Try
                        testzip.OpenRead(gsUnzipPassword)
                        testzip = Nothing
                        Return PasswordTest.ProtectedAndSucceeded
                    Catch ex As Exception
                        MsgBox(“Incorrect Password!”, MsgBoxStyle.OkOnly Or MsgBoxStyle.Information, PRODUCT_NAME)
                        gsUnzipPassword = String.Empty
                        gbUnzipPassprotect = False
                        Return PasswordTest.ProtectedAndFailed
                    End Try
             

               End if

    End if

    The problem is that TestZip.OpenRead(gsUnzipPassword) throws an exception: “System.NullReferenceException = {“Object reference not set to an instance of an object.”}”

    This doesn’t make sense to me – what am I doing wrong?

     All I am trying to do is verify that the password a user has entered (it is the default password entered when the archive was created) is the correct one.

    I swear this code used to work – but I just updated to 5.0 and it doesn’t.     I also tried the latest version of 4.2 and it didn’t work either – so if it ever worked it was broken some time ago…   I’m 90% sure this worked in an earlier version of 4.2…

    Des

    Imported from legacy forums. Posted by Dan (had 1649 views)

    Diane [Xceed]
    Moderator
    Post count: 1353

    Hi Dan,

    When you get the exception, could you “drill down” the inner exceptions and report them to us? This will allow us to know the real cause behind the exception you are getting.

    Each System.Exception object contains an InnerException property. You can loop on each inner exception, taking note of each exception along the way until InnerException is null.

    Example (C#):

       try
       {
          // TODO: Code that causes an exception
       }
       catch( Exception exception )
       {
          // Output some information about it
          Console.WriteLine( “–>{0}: {1}\n{2}”, exception.GetType().Name, exception.Message, exception.StackTrace );

          // Fetch the inner exception
          exception = exception.InnerException;

          // While there is an exception
          while( exception != null )
          {
             // Output some information about it
             Console.WriteLine( “–>Inner exception: {0}: {1}\n{2}”, exception.GetType().Name, exception.Message, exception.StackTrace );

             // Fetch the inner exception
             exception = exception.InnerException;
          }
       }

    Example (VB.NET):

       Try
          ‘ TODO: Code that causes an exception
       Catch exception As Exception
          ‘ Output some information about it
          Console.WriteLine(“–>{0}: {1}” & Constants.vbLf & “{2}”, exception.GetType().Name, exception.Message, exception.StackTrace)

          ‘ Fetch the inner exception
          exception = exception.InnerException

          ‘ While there is an exception
          Do While exception IsNot Nothing
             ‘ Output some information about it
             Console.WriteLine(“–>Inner exception: {0}: {1}” & Constants.vbLf & “{2}”, exception.GetType().Name, exception.Message, exception.StackTrace)

             ‘ Fetch the inner exception
             exception = exception.InnerException
          Loop
       End Try

     

    Imported from legacy forums. Posted by Diane [Xceed] (had 283 views)

    User (Old forums)
    Member
    Post count: 23064

    Diane:

    Thanks – I will get the information to you shortly.    Actually I wound up rewriting the code over the weekend – but it too is having a problem with password protection – so it all may be related.   

     

    Imported from legacy forums. Posted by Dan (had 265 views)

    User (Old forums)
    Member
    Post count: 23064

    Diane:

    In the testing you suggested I believe I found the problem.    I am doing something to the compressed file I probably shouldn’t be doing – but there is actually a very good reason.    All zip files begin with the header PK (Remember Phil Katz?).    I remove that and replace it with WX.    In the past (earlier versions of 4.2 and all previous versions of the .net zip libs I’ve used) this has not had any ill effect upon the methods within the XcEEd libraries – until now.

    The reason I change this is because I have created a “different structure” within the zip – nothing illegal, just different.   These are archives for our proprietary system (its a Weather Graphics system).   I give the file a .WXC extension instead of .ZIP.     Although zip utilities could be used to get at the contents – the proper directory structure would not be honored.    Unfortunately Microsofts Internet Explorer (6, 7 and 8) takes it upon itself to RENAME  any file with the PK header to .ZIP whenever you use it to download the file.    So – when our customers use IE to download one of our .WXC files they become .ZIP thanks to Microsoft trying to be so stinking clever.

    The problem is odd – because there are other places in the code where I unzip these files with the WX header – and it does not complain at all.    I do not know why it complains sometimes – and not at others.   

    Is there anything I can do to force XcEEd to ignore the header issue?

     

    Imported from legacy forums. Posted by Dan (had 269 views)

    Diane [Xceed]
    Moderator
    Post count: 1353

    Hi Dan,

    Here is the answer I received from the developer:

    You cannot change the format of your zip files and expect the component to work with them without issue, present or future. If you change the header signatures, the component might not be able to find items, or might treat them as garbage data.

    We cannot provide support for “zip” files with a custom format.

    Previous versions probably only worked by chance.

    With version 4.2, we made massive changes to the component internally to make certain operations faster. It probably broke whatever made your scenario work.

    If you had a previous version that worked with your custom zip files, you should stick with that version and not upgrade.

    Another solution would be for you to purchase the source code of the component (the Blueprint Edition) and modify the component to support your custom format.

     

    Imported from legacy forums. Posted by Diane [Xceed] (had 383 views)

    User (Old forums)
    Member
    Post count: 23064

    I understand.   I think your developers response is really the correct and only supportable one your company could give me.    I knew that ice was thin when I walked out on it! [:D]

    I have found a way around the problem.   Return the header to normal (PK) just before I pass the file into any of the XcEEd methods works perfectly.   I then return the header to what I need (WX) when I’m done.    

    Sorry for the fire drill.

     

    Des

    Imported from legacy forums. Posted by Dan (had 1698 views)

Viewing 6 posts - 1 through 6 (of 6 total)
  • You must be logged in to reply to this topic.