I am working with a tool that keeps the project in a zipped archive, is there a version control system that uses the diffs of the extracted files instead of the binary thing that the archive is?
Related
I have written a Java program to zip files and to unzip them in an unzipping C program called Junzip.
https://github.com/jokkebk/JUnzip. I'm able to unzip the file using 7zip file extractor. But when using C Junzip, its not unzipping.
But when I'm unzipping the file, which was zipped using normal file compressor, I'm able to unzip it using the same jUnzip library.
Author of the JUnzip library here, just came across this question. Did I understand correctly that .zip files made by your program unzip correctly with 7zip, but not with JUnzip, whereas JUnzip seems to be able to uncompress .zip files made by others?
Without further info, it's hard to say if there's a .zip feature you are using that JUnzip does not support, or if there's a bug in JUnzip. One possible reason is that the library and junzip.exe only supports a limited set of compression methods, namely Deflate that is supported by zlib library it uses. The code base is rather small so you could probably add a few debug statements to see where it goes wrong.
You can check out https://codeandlife.com/2014/01/01/unzip-library-for-c/ for some details regarding JUnzip.
I am searching for a way to access the data contained in a dump file of Wikipedia's georeferencing project offered on this site at the bottom of the righthand box. download link
After unpacking the .gz archive, a 4.7GB file named new_red0 remains without any file extension.
Can anyone help me open this file using Windows 10?
I have an SSIS File System deployment and I am trying to understand if there is any easy way to deploy a large number of packages. The name implies that it is a physical directory on the disk, that I could copy/paste the files to, but I cannot find anything online that tells me where this directory lives.
Am I correct in thinking it works this way? Or will I need to either manually upload each package in SSMS or script an automated deployment
Your current files reside in:
\[your]\[computer]\pdevine\Documents\Visual Studio [yourVersion]\Projects
After creating a solution on the target, you can just copy and paste the files into the project directory for the target. If you don't know where to find your current files, click on any package and look here:
Firefox store its default configuration information in omni.jar (older version) or omni.ja (later versions). Both omni.jar and omni.ja just are zip file format. So we can use many programs/libraries to compress or decompress them.
I want to get some default information of Firefox. So I must read some file in those omni file. I have used 7zip program to see the content of omni or MiniZip/Zlib library to read omni in my program.
With later version, omni.ja, it is read well. But with older versions, MiniZip cannot open the omni.jar file. Then I use 7zip to open those file: omni.ja was ok, omni.jar was fail. But with some other program, ex: WinRar, WinZip, ... both omni file is opened well.
I was google and get some information: with older version, Firefox has created the omni.jar file (a zip file format) with no zip standard. blah blah. But why WinRar or WinZip can read.
Anyone can help me to get MiniZip read omni.jar file with no error?
Thank you very much.
The solution is pretty simple: Your "old" omni.jar is broken. My omni.jar starts with PK.
I suggest to download Firefox from the official archive once more.
[EDIT] It seems that different builds of Firefox use different tools to built the ZIP archive. The en-US version uses a ZIP-like format which doesn't start with PK. While in theory the file format is valid (it contains data followed by the list of entries), almost no tool really supports this format (so WinZIP and WinRAR are the exceptions).
This intention is reflected by the rename of omni.jar to omni.ja: It's not encrypted, it's just a ZIP format that isn't widely supported and the US Firefox developers don't want to change this.
The other developers (for example for the de version) use official tools to build the omni archive so those versions can be modified with any tool.
You will need to find a way to update the archive using WinZIP / WinRAR or you need to download the original firefox sources and add your patches to the build process.
I've used the "Reduce XAP size by using Application library caching" setting. I see that some dlls are now excluded from the .xap file but some aren't, specifically
System.Reactive.dll
System.Windows.Controls.DataVisualization.Toolkit.dll
System.Windows.Controls.Theming.Toolkit.dll
System.Windows.Controls.Toolkit.dll
Any idea why this is the case?
thanks
The "Reduce XAP size" feature only leaves DLLs out of the XAP where there's a .extmap file next to the DLL (for examples, you can look at any of the SDK assemblies under \Program Files (x86)\Microsoft SDKs\Silverlight\vX.0\Libraries\Client and their respective extmap files). The assemblies that are still being included probably are either missing the extmap file, or it's somehow improperly defined.
What version of the toolkit are you using?
In VS open the References folder and select one of these dlls. Then look at the Path value in the properties of that reference. Open the folder that contains the dll.
Present in that folder should be a matching *.extmap.xml. This file is used in creating the external zip file for the dll. If this file isn't present then regardless of the "Reduce XAP size by using Application library caching" setting the dll will still be included in the XAP.
The latest versions of the Toolkit (Nov09 for SL3 and Apr10 for SL4) both include a set of these extmap.xml files. However if you have the practice of copying such library files into your project (commonly people use "Libs" sub-folder under the project) then you may not have copied these files.