Archived Forum Post

Index of archived forum posts

Question:

ExtractInto call failing sporadically (Zip)

Aug 12 '16 at 16:40

Hello, I am having this strange issue where I am issuing an ExtractInto call on a ZipEntry. I am unable to find an example of how to check for error. I am using events OnAbortCheck and OnPercentDone. I am checking if (!zipEntry.LastMethodSuccess) to throw an error to the user. Is this the correct way? Can anyone point me to an example to trap errors inside the method call. Any help is appreciated.

---

Answer

Here is the full lasterrortext

LastError Text

ChilkatLog:
  ExtractInto(462918ms):
    DllDate: Mar 11 2016
    ChilkatVersion: 9.5.0.56
    UnlockPrefix: SHAREC.ZPX0617
    Username: AISDEVWS01:kpratap
    Architecture: Little Endian; 32-bit
    Language: .NET 4.0
    VerboseLogging: 1
    inflateToBaseDir(462918ms):
      inflateMappedEntry(462918ms):
        inflateToOutput2(462871ms):
          mappedInflateToOutput(462871ms):
            loadLocalFileHeader(62ms):
              localHeaderExtraFields:
                extraHeaderId: 0x9901
                extraHeaderLen: 7
                extraHeaderId: 0xa
                extraHeaderLen: 32
              --localHeaderExtraFields
            --loadLocalFileHeader
            wzDecryptInit:
              mode: 3
              saltSize: 16
              fcrypt_init:
                mode: 3
                ZipAes_derive_key:
                  salt: A0F0 C98E A7AA 23FF 7E97 3024 3860 B4BD
                  salt_len: 16
                  key_len: 66
                  key: D52F E5F1 EE1E AF22 A7B8 D20F 9B8F A9BF
502D 064D 2198 7DC1 8339 C1A3 727E 4883
06E0 240E 2BE1 66AE FFCA A8D9 5738 8A6F
CC1C 0BC4 A7BC EA6D AAF9 F311 4F92 F787
90C1
                --ZipAes_derive_key
                key_length: 32
                kbuf: D52F E5F1 EE1E AF22 A7B8 D20F 9B8F A9BF
502D 064D 2198 7DC1 8339 C1A3 727E 4883
                passwordVerifier: 90C1
              --fcrypt_init
              aesVerificationBytes: 90C1
            --wzDecryptInit
            fromDeflated(462809ms):
              inflateFromSource(462809ms):
                inflateSource(462637ms):
                  WindowsError: The handle is invalid.
                  Failed to read file bytes to buffer.
                  Failed to get bytes at current index.
                  curIndex: 145686698
                  Data source read failed.
                --inflateSource
                Inflate from source failed.
              --inflateFromSource
            --fromDeflated
          --mappedInflateToOutput
        --inflateToOutput2
        Unzip failed
        path: C:UserskpratapDocumentsf53exhnq.4puENTIREFILE.PDF
      --inflateMappedEntry
    --inflateToBaseDir
    Failed.
  --ExtractInto
--ChilkatLog

---

OK

---

Answer

My only guess as to the cause of the problem is that you have multiple threads operating at the same time. Perhaps one thread is calling ZipEntry.ExtractInto, while another thread is closing the Zip object?

Could this be possible?

---

Answer

I was thinking the same thing about using a network drive. When I run from my dev machine connecting to this zip file, I have never had an issue so far. When I run from a RDP machine (it might be a virtual one), I get occasional issues. The QA person seems to get it a lot more from the QA workstation. Am I doing the right thing in terms of checking for error like this.

    public void OnAbortCheck(object source, Chilkat.AbortCheckEventArgs args)
    {
        if (!zipEntry.LastMethodSuccess)
        {
            _Cancelled = true;
            _lastErrorText = zipEntry.LastErrorText;
            ErrorLog.Logger.RecordError(new Exception("Unexpected Error on extract", new Exception(_lastErrorText)));
            lblUnzipStatus.Text = "Unexpected Error on extract, operation cancelled. Please retry. ";
            buttonViewPdf.Enabled = true;
            buttonViewPdf.Text = "View PDF Image";
        }
        if (_Cancelled)
        {
            args.Abort = true;
            lblUnzipStatus.Text += "..Extract cancelled.";
        }
        Application.DoEvents();
    }

Here is the ExtractInfo call. zipEntry.VerboseLogging = _isDevQa;

        zipEntry.HeartbeatMs = 200;
        zipEntry.EnableEvents = true;
        zipEntry.OnPercentDone += OnPercentDone;
        zipEntry.OnAbortCheck += OnAbortCheck;
        _lastErrorText = string.Empty;
        _success = zipEntry.ExtractInto(docPath);

My main focus right now is to trap the error and ask the user to try again. Am I checking for the error correctly? This is a Winforms application, btw.

---

Answer

There's no reason to try to trap the error because when the error occurs, the method (ExtractInfo) returns immediately. The AbortCheck would only be used if you want to provide a means for aborting a method call that is humming along just fine without any errors.

(Also, the LastMethodSuccess wouldn't be set until the method is already in the act of returning.)

---

Answer

Essentially, should I then check _success after the ExtractInfo Call? Am a bit confused.