LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

MGI SZL problems when using List Zip Contents.vi

I'm using the MGI SharpZipLib library so that I can get around the known issue with 2GB file size limits for zip files using the native and OpenG libraries. When I try to verify if a file is already present in the zip using the List Zip Contents VI, it causes havoc and throws errors.

 

Here's what I've come up with:

  • If the zip file doesn't already exist and I don't list the contents, things go as expected: files all get zipped, are the correct size, no reported errors or warnings. Files can be opened in Windows explorer without issue.

 

  • If the zip file doesn't already exist and I do list the contents, the archive created is 0 bytes and I get a NullReferenceException in List Zip Contents.vi:
    • Error 1172 occurred at Constructor Node Error creating instance of DiskArchiveStorage in assembly ICSharpCode.SharpZipLib.Zip.DiskArchiveStorage, ICSharpCode.SharpZipLib, Version=0.86.0.518, Culture=neutral, PublicKeyToken=1b03e6acf1164f73, (System.NullReferenceException: Object reference not set to an instance of an object.)

 

  • If the zip file already exists and I don't list the contents, I get a System.NotSupportedException error in Add File.vi:
    • Error 1172 occurred at Invoke Node System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.
      Inner Exception: System.NotSupportedException: Stream does not support writing. 

 

  • If the zip file already exists and I do list the contents, I get the above System.NotSupportedException error in Add file.vi :
    • Error 1172 occurred at Invoke Node System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.
      Inner Exception: System.NotSupportedException: Stream does not support writing.

       

 

In all cases, the archives seem to be OK to open with Windows Explorer, so they don't appear to be corrupt.

 

Anyone had this problem before or know of a better way to see if a file exists in the zip archive?

 

Oh, using LV2014 SP1 x64 on Win10.

 

Thanks!

Cranky

 

0 Kudos
Message 1 of 6
(2,433 Views)

If  you have a problem with the MGI Library (which uses SharpZipLib), you might get in touch with David Moore, of Moore Good Ideas, who probably "pointed" you to this method.  If anyone is likely to have a suggestion, he'd be my best guess (and he truly does have Good Ideas).

 

Bob Schor

0 Kudos
Message 2 of 6
(2,409 Views)

Hi Bob,

 

I was thinking the same thing, but wanted to post the issue publicly, for posterity. I'll try and get a hold of them through their site.

 

Thanks!

0 Kudos
Message 3 of 6
(2,389 Views)

Looking inside Add File.vi, the error is thrown by ZipFile.CommitUpdate. The specific error code description comes from the Write() method, which is way down the call chain from CommitUpdate.

 

                        /// <summary>
			/// Writes a sequence of bytes to the current stream and advances the current position within this stream by the number of bytes written.
			/// </summary>
			/// <param name="buffer">An array of bytes. This method copies count bytes from buffer to the current stream.</param>
			/// <param name="offset">The zero-based byte offset in buffer at which to begin copying bytes to the current stream.</param>
			/// <param name="count">The number of bytes to be written to the current stream.</param>
			/// <exception cref="T:System.IO.IOException">An I/O error occurs. </exception>
			/// <exception cref="T:System.NotSupportedException">The stream does not support writing. </exception>
			/// <exception cref="T:System.ObjectDisposedException">Methods were called after the stream was closed. </exception>
			/// <exception cref="T:System.ArgumentNullException">buffer is null. </exception>
			/// <exception cref="T:System.ArgumentException">The sum of offset and count is greater than the buffer length. </exception>
			/// <exception cref="T:System.ArgumentOutOfRangeException">offset or count is negative. </exception>
			public override void Write(byte[] buffer, int offset, int count)
			{
				baseStream_.Write(buffer, offset, count);
			}

/// <summary>
/// Writes a sequence of bytes to the current stream and advances the current position within this stream by the number of bytes written.
/// </summary>
/// <param name="buffer">An array of bytes. This method copies count bytes from buffer to the current stream.</param>
/// <param name="offset">The zero-based byte offset in buffer at which to begin copying bytes to the current stream.</param>
/// <param name="count">The number of bytes to be written to the current stream.</param>
/// <exception cref="T:System.IO.IOException">An I/O error occurs. </exception>
/// <exception cref="T:System.NotSupportedException">The stream does not support writing. </exception>
/// <exception cref="T:System.ObjectDisposedException">Methods were called after the stream was closed. </exception>
/// <exception cref="T:System.ArgumentNullException">buffer is null. </exception>
/// <exception cref="T:System.ArgumentException">The sum of offset and count is greater than the buffer length. </exception>
/// <exception cref="T:System.ArgumentOutOfRangeException">offset or count is negative. </exception>
public override void Write(byte[] buffer, int offset, int count)
{
throw new NotSupportedException();
}

 Is it possible that something in the List Zip Contents.vi is clobbering something else in the zip file and preventing the stream from being accessible?

 

The crazy thing is that I swear I had it working correctly once, but only once. Attached is a version that automatically lists the contents if the archive exists.

0 Kudos
Message 4 of 6
(2,387 Views)

So after more experimenting, it loooks like any attempt to add files to an existing zip archive throws the System.NotSupportedException. Very frustrating.

 

I haven't heard back from MGI, nor from the SharpZipLib folks on their github site. It occurred to me that this might be related to antivirus software,

but I'll have to fight with IT to get anywhere with testing that out.

 

In the unlikely event that I get resolution to this, I'll try and remember to post an update.

0 Kudos
Message 5 of 6
(2,359 Views)

Just posting an update for posterity.

 

  • Worked with IT support to determine if it's an antivirus issue. No logs generated by the AV software when attempting to add files to an existing .zip. No system errors or notifications in the Windows system logs either.
  • Got a single response on the GitHub site for SZL. User was unable to reproduce the issue. Upgrading my local .dll to the latest release (1.0.0) did not solve the problem.
  • Never heard back from MGI, not sure it's worth it to pursue since the error isn't caused by their function calls to the .dll anyway.
  • Tried a beta version of the OpenG library from RolfK but can't install it due to some un-explainable file permissions behavior when trying to access the RT target portion of the install.
  • Tried to find an alternative but have been unsuccessful. Can't use 7-Zip as a .dll because there are no header files.

I'm aware that I could just run something else on the command line, but these operations can take 30-90 minutes to complete. I'm not cool with just leaving the LabVIEW front panel with a stopped progress bar and a busy cursor because it just looks like the program is stuck.

 

So I'm basically waiting for RolfK to find the time to update the OpenG installer so that it doesn't bonk as the next step.

0 Kudos
Message 6 of 6
(2,279 Views)