Cannot Read That As A Zip File Dotnetzip
Katerine Aldrige
I am trying to use DotNetZip 1.9 to read an uploaded zip file in Asp.Net MVC 3.I already verified that the HttpPostedFileBase object I receive is fine. I can save it to disk and then unzip it. However, saving to disk first seemed wasteful since I should be able to unzip from memory directly.
I suspect that the ZipFile.IsZipFile method call has advanced your InputStream position and when you try to read it later it is no longer a valid zip file since the stream position has moved. Try sticking a
SharpZipLib includes good support for zip. I've written about it a few times, and I think it's great. Unfortunately, it's under a wacky "GPL but pretty much LGPL" license - it's GPL, but includes a clause that exempts you from the "viral" effects of the GPL:
Linking this library statically or dynamically with other modules is making a combined work based on this library. Thus, the terms and conditions of the GNU General Public License cover the whole combination. As a special exception, the copyright holders of this library give you permission to link this library with independent modules to produce an executable, regardless of the license terms of these independent modules, and to copy and distribute the resulting executable under terms of your choice, provided that you also meet, for each linked independent module, the terms and conditions of the license of that module.
I'm pretty sure that the reason for this odd "sort-of-GPL" license is because some of the SharpZipLib is based on some GPL's Java code. However, most companies have policies which forbid or greatly restrict their use of GPL code, and for very good reason: GPL has been set up as an alternative to traditional commercial software licensing, and while it's possible to use GPL code in commercial software, it's something that requires legal department involvement. So, my bottom line is that I can't use your code due to your license.
UPDATE: DotNetZip has been released on CodePlex, and the one issue I ran into has been fixed. I'd recommend giving this a try instead of System.IO.Packaging (as I'd originally recommended), because it's a lot easier to use.
The Zip format allows for several different compression methods, but the most common is Deflate. System.IO.Compression includes a DeflateStream class. You'd think that System.IO would include Zip, but... no. The problem is that, while System.IO.DeflateStream can write to a stream, it doesn't write the file headers required for Zip handlers to read them.
The resulting Zip will contain File.txt, but it will be within the \My Documents\Sample\ hierarchy. There's no way to control the structure of the zip file when you add individual files, unless you want to modify the zip library (which is under MsPL license). That proved to be a big problem in my case, because the zip structure I'm creating is pretty rigid. So, if you're just zipping an entire folder full of files, this library may work for you, but if you need more control you may need to modify the library. I'm guessing if this were published on CodePlex it would have been fixed a while ago.
Another larger problem to keep in mind is that stream based compression is much less efficient than file based compression. File compression can optimize the compression used based on the content of all included files; stream based compression compresses data as it comes in, so it can't take advantage of data it hasn't seen yet.
J# has included zip since day one, to keep compatible with the Java libraries. So, if you're willing to bundle the appropriate Java library (specifically, vjslib.dll), you can use the zip classes in java.util.zip. It works, but it seems like a really goofy hack to distribute a 3.6 MB DLL just to support zip.
In .NET 3.0, you can use the the System.IO.Packaging ZipPackage class in WindowsBase.DLL. It's just 1.1 MB, and it just seems to fit a lot better than importing Java libraries. It's not very straightforward, but it does work. The "not straightforward" part comes from the fact that this isn't a generic Zip implementation, it's a packaging library for formats like XPS that happen to use Zip.
First, you'll need to find WindowsBase.dll so you can add a reference to it. If it's not on your .NET references, you'll probably find it in C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.0\WindowsBase.dll.
One weird side-effect of using the ZipPackage to create Zips is that Packages contain a content type manifest named "[Content_Types].xml". If you create a ZipPackage, it will automatically include "[Content_Types].xml"., and if you try to read from a ZIP file which doesn't contain a file called "[Content_Types].xml" in the root, it will fail.
You'll notice that the compression in my test is not that great. In fact, pretty bad - Notepad.exe got bigger. Binary files don't compress nearly as well as text-based files - for example, I tested on a 55KB file and it compressed to less than 1KB - but the compression in this library doesn't appear to be fully implemented yet. For example, the CompressionOption enum includes CompressionOption.Maximum, but that setting is ignored. Normal is the best you'll get right now.
Another possible reason for low compression ratios in this sample is that I'm adding files separately rather than adding several files at a time. As I mentioned earlier, Zip compression works better when it has access to the entire file or group of files when creating the archive.
That's a good question. All the Zip handling in System.IO.Packaging is in an internal class MS.Internal.IO.Zip. It would have been a lot more useful to implement a public System.IO.Zip which was used by System.IO.Packaging so that we could directly create and access Zip files without pretending we were creating XPS packages with manifests and Uri's.
I recently upgraded my alteryx version from 2020.4 to 2021.4. I have an Analytic App workflow which contains multiple input tools that are pointed at .zip files. Each zip file contains a folder and multiple files. The zip file and sub-folder use standardized names that also contain year and quarter . The file and sheet names are standardized. I am using the input tool where the path contains user input variables that allows a dynamic input dependent on year and quarter. The workflow ran with no errors on version 2020.4, but after upgrading the application, i am receiving the error, 'the system cannot find the path specified'. I changed the input tool to point directly at the zip file, sub-folder, file and sheet using the connect a file browsing tool. Even pointed at the exact file, i am still getting an error.
I found the attached discussion, The system cannot find the path specified - Alteryx Community, that appears like this might be a known issue. If so, what is the resolution and/or are there any other methods of opening the .zip files?
I only start using Alteryx today, and I am using v 2022.3.1.450 Patch 2, which is the latest. I was tying to read an excel file from a zip file similar to the above situation, and I was getting the same error. I have tried few times to isolate the reason of the issue (like special characters in the Zip file name, or the zipped file inside) and both didn't help. But I found that the real issue was based on the Zip file name size (number of characters) and the file that need to be unzipped name size (number of characters too.) which prevent Alteryx from the ability to extract the file into a temporary folder because any folder/file in Windows does not allow any file/folder to exceed more than 256(or 260) characters in total. e.g. C:\Users\\AppData\Local\Temp\Engine_\Zip_
Alteryx error: "The system cannot find the path specified" is in fact wrong and should have been displayed as "Unable to extract the target file, long name under Temp folder." so at least the user can easily fix the problem, rather than spending hours wasted.
by the way, even if this is a work around, there is a way to improve that if Alteryx themselves corrected that issue by reducing that large name they create under a temp folder, or at least be able to handle a long name path (which is not a default by Windows but it is possible, I've done that in my own programing before.)
If you are still facing the long name issue, here is another solution. you can change the default Temp folder location to much shorter like ("C:\") from under the Workflow - Configuration > Runtime > Temporary Files > Use Specific Folder .. and change the Path to new target shorter name.
How exactly are you extracting the files? Are you using the command-line or the GUI? Are you dragging the files or selecting them and using the extract function? Are you using the shell-extension context-menu?
If you enter a destination folder and then select the extract function or use the shell-extension, then they do not extract to a temporary folder first, they extract directly to the destination.
If they didn't use the filesystem, decompression would happen in memory. Under low memory conditions, or for large compressed files this would sooner or later exhaust available memory and start the process of memory paging.
Paging under these circumstances would be a lot slower than just using the filesystem because the file is still being decompressed (and page files keep being added), but also because as the file is being decompressed, it is being checked for errors and there's as such a lot of read/write operations. The worst thing that can happen to a page file.
EDIT:Regarding the use of a temporary directory, this is so to follow many operating system guidelines. If the decompression fails, there's no guarantee the program performing the operation cleans up after itself. It may have crashed for instance. As such, no residual file remains in your target directory and the operating system will dispose of the temporary file when it sees appropriate.
Now, you might know that your filesystem might have enough space, however the application does not. What if that filesystem is in use by the OS or another application and gets filled up while decompressing?
7fc3f7cf58