|
how can i use it in eVC????
Thanks ahead
|
|
|
|
|
I tried writing a simple program that would open a zip file and extract all of its files. I started by including XUnzip.h and I got a complaint from Visual C++ 6.0: "error C2065: 'HZIP' : undeclared identifier". I disabled precompiled headers, but I don't understand what's going on.
Help anyone?
|
|
|
|
|
I solved it by including windows.h and remember to do rebuild all when you changed a .h file, or you will get the same error over and over.
|
|
|
|
|
Hello,
I am using your code and it works great when I had files into my zip file.
But now I would like to add a folder and am using
ZRESULT zr = ZipAdd(hZipFile, _T("c:\\TestDir"), 0, 0, ZIP_FOLDER);
It returns zero but the resulting zip file is empty. I traced a bit of the code and it seems the destination becomes "c" only (converted to a char) but even fixing this didn't seem to help.
Any suggestions?
|
|
|
|
|
ZIP_FOLDER adds a folder in the zip. You could use this function
BOOL AddFolderContent(HZIP hZip, CString Path, BOOL Recurse, CString SubDir="")
{
_finddata_t fds ;
long Finder ;
CString Mask,FullPath, File, FileInZip ;
if (SubDir.GetLength())
{
ZipAdd(hZip,(LPCSTR)SubDir,0,0,ZIP_FOLDER);
}
Mask.Format("%s*.*", Path);
fds.attrib = _A_NORMAL ;
Finder = _findfirst(Mask, &fds) ;
if (Finder != -1)
{
while (1)
{
try
{
File = fds.name ;
if (File.CompareNoCase("..") && File.CompareNoCase("."))
{
if ( (fds.attrib & _A_SUBDIR)==0 && (fds.attrib & _A_SYSTEM)==0 )
{
FullPath.Format("%s%s", Path, fds.name);
if (SubDir.GetLength())
{
FileInZip.Format("%s\\%s", SubDir, fds.name);
}
else
{
FileInZip = fds.name ;
}
cout << "Adding file " << fds.name << endl ;
if (ZipAdd(hZip, (LPCSTR)FileInZip, (LPVOID)(LPCSTR)FullPath, 0,ZIP_FILENAME)!=ZR_OK) return FALSE ;
}
else
{
if (fds.attrib & _A_SUBDIR && Recurse)
{
CString TempSubDir ;
CString TempPath ;
if (SubDir.GetLength())
{
TempSubDir.Format("%s\\%s", SubDir, fds.name);
}
else
{
TempSubDir = fds.name;
}
TempPath.Format("%s%s\\", Path, fds.name);
if (AddFolderContent(hZip, TempPath, TRUE, TempSubDir)== FALSE)
{
return FALSE ;
}
}
}
}
}catch(...)
{
}
if (_findnext(Finder, &fds)==-1) break;
}
}
_findclose( Finder );
return TRUE;
}
|
|
|
|
|
Same function but not using MFC
Performance of this algo : 1GB of txt files (unicode) takes 7'35 min to zip. Output file is 53 MB
Performance of WinRAR : 1GB of txt files (unicode) takes 6'25 min to zip. Output file is 35 MB
/**
* Added by Renaud Deysine. This fonctionnality was missing in API
* @brief Add a folder to the zip file. Empty folders will also be added.
* This method add recursively the content of a directory
* @param AbsolutePath like "C:\\Windows" or "C:\\Windows\"
* @param DirToAdd like "System32"
*
*/
BOOL AddFolderContent(HZIP hZip, TCHAR* AbsolutePath, TCHAR* DirToAdd)
{
HANDLE hFind; // file handle
WIN32_FIND_DATA FindFileData;
TCHAR PathToSearchInto [MAX_PATH] = {0};
if (NULL != DirToAdd)
{
ZipAdd(hZip, DirToAdd, 0, 0, ZIP_FOLDER);
}
// Construct the path to search into "C:\\Windows\\System32\\*"
_tcscpy(PathToSearchInto, AbsolutePath);
_tcscat(PathToSearchInto, _T("\\"));
_tcscat(PathToSearchInto, DirToAdd);
_tcscat(PathToSearchInto, _T("\\*"));
hFind = FindFirstFile(PathToSearchInto,&FindFileData); // find the first file
if(hFind == INVALID_HANDLE_VALUE)
{
return FALSE;
}
bool bSearch = true;
while(bSearch) // until we finds an entry
{
if(FindNextFile(hFind,&FindFileData))
{
// Don't care about . and ..
if(IsDots(FindFileData.cFileName))
continue;
// We have found a directory
if((FindFileData.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY))
{
TCHAR RelativePathNewDirFound[MAX_PATH] = {0};
_tcscat(RelativePathNewDirFound, DirToAdd);
_tcscat(RelativePathNewDirFound, _T("\\"));
_tcscat(RelativePathNewDirFound, FindFileData.cFileName);
// Recursive call with the new directory found
if (AddFolderContent(hZip, AbsolutePath, RelativePathNewDirFound)== FALSE)
{
return FALSE ;
}
}
// We have found a file
else
{
// Add the found file to the zip file
TCHAR RelativePathNewFileFound[MAX_PATH] = {0};
_tcscpy(RelativePathNewFileFound, DirToAdd);
_tcscat(RelativePathNewFileFound, _T("\\"));
_tcscat(RelativePathNewFileFound, FindFileData.cFileName);
if (ZipAdd(hZip, RelativePathNewFileFound, RelativePathNewFileFound, 0, ZIP_FILENAME) != ZR_OK)
{
return FALSE;
}
}
}//FindNextFile
else
{
if(GetLastError() == ERROR_NO_MORE_FILES) // no more files there
bSearch = false;
else {
// some error occured, close the handle and return FALSE
FindClose(hFind);
return FALSE;
}
}
}//while
FindClose(hFind); // closing file handle
return true;
}
Renaud Deysine
|
|
|
|
|
Hi All,
I want to know how can i do compression on the fly? I need to compress data before sending them on the wire between 2 computers and gets uncompressed upon reaching the other computer. Any suggestions, alorithum or functions that i can use? Also is there any way to change XZip/UnZip in .Net(C#)?
I dont want to use the J# functions
thanks
a lot
|
|
|
|
|
A method would be build the stream into packets which can then be compressed individually, before being sent. Any compression algorithm would do, eg. Zip Deflate. It would be best to try different algorithms, and see which one gives you the best compression. It's also worth trying different packet sizes.
It's also worth generating a hash of the packet, to be appended to the packet when sent, enabling
the receiving end to determine if transmission error occurred.
|
|
|
|
|
Hi All,
I want to know how can i do compression on the fly? I need to compress data before sending them on the wire between 2 computers and gets uncompressed upon reaching the other computer. Any suggestions, alorithum or functions that i can use? Also is there any way to change XZip/UnZip in .Net(C#)?
I dont want to use the J# functions
thanks
a lot
|
|
|
|
|
Hi,
Does anyone know where I can find sample code for archiving in the cab format?
Thanks!
|
|
|
|
|
Hi,
I want to add streaming unzip feature to my app i.e. I receive the contents of the zip file as a stream of data, and need to unzip the incoming data without waiting for the complete file to arrive. Is there an easy way to reuse the code in XUnzip to achieve this?
Thanks,
Roshan
|
|
|
|
|
Did anybody used it in UNICODE build ?
It cribs a lot for all function definitions passing TCHAR and all..
Please let me know..
I think will have to port it for UNICODE then
thanks and regards,
Vikram
|
|
|
|
|
Great code, after speindgin two days trying to get unzi32.dll and .lib to work with my c++ project, you code worked in an instant.
I am having a problem unzippin a zip file which contains directories. It unzips the files fine but all dirs are put in an upper level dir and the files within the dirs are not there.
exp:
zip file contents
foo.c
foo.h
temp\foo.h
if foo.zip is in c:\data and its the working dir then here is what I get
c:\data\foo.c
c:\data\foo.h
c:\temp
Any ideas?
Thanks
Vince
|
|
|
|
|
Hi Vince,
I had the same problem, but tracked it down to this:
in XUnzip.cpp, line 4010 reads:
_tcscat(cd,name);
while it should read:
_tcscat(cd,dir);
I made that change in my XUnzip.cpp, and now it works fine.
Hope it works for you also
Craig
|
|
|
|
|
Can I delete a file from the zip?
|
|
|
|
|
I try to add a new file in a existing zip with the following commands:
hz = OpenZip(pszArchive2, 0, ZIP_FILENAME);
if(ZipAdd(hz, pszName3, pszName3, 0, ZIP_FILENAME) == ZR_OK)
{
m_List.Printf(CXListBox::Red, CXListBox::White, 0,
_T(" Am adaugat in arhiva"));
}
else
{
m_List.Printf(CXListBox::Red, CXListBox::White, 0,
_T(" Nu am adaugat in arhiva"));
}
CloseZip(hz);
but this things doesn.t work.
How can I add a new file in a existing zip????
|
|
|
|
|
In TUnzip::Get the evaluation of ufi.external_fa returns invalid results, if the upper half (unix attributes) is not set at all for some reason (=0x0000xxxx). In this case uwritable gets false and later FILE_ATTRIBUTE_READONLY is set.
I think, if the unix attributes are not set at all, you should not evaluate them. Obviously e.g. Winzip or the Windows-XP-Buildt-In-Zip are able to handle missing unix attributes correcltly.
By the way, I have created the zip file with the missing unix attributes with the so called internal zip of "Total Comander 5.51".
Thomas Haase
|
|
|
|
|
Is it possible to create multiple archives. (e.g. 1.44mb)
Thanks,
Marco
|
|
|
|
|
line 3652 :
if (err==Z_STREAM_END) return (iRead==0) ? UNZ_EOF : iRead;
to
if (err==Z_STREAM_END) return (iRead==<code>len</code>) ? UNZ_EOF : iRead;
As iRead is an accumulator of the ZIP output buffer, if Z_STREAM_END is reached, UNZ_EOF is get if the total output bytes equal the expected len !
Kochise
PS : Especialy in ZIP_MEMORY mode !!!
In Code we trust !
|
|
|
|
|
This code is part of zlib, and I assume that is well tested.
Thomas Haase
|
|
|
|
|
Thanks Kochise
This is definitely a bug.
|
|
|
|
|
For some unknown reasons, I inflate a CAB file with odd (300937 bytes) size.
err=inflate(&pfile_in_zip_read_info->stream,flush); The previous line returns me Z_OK intead of Z_STREAM_END at the end of the zipped file, so it fails to the following line in int unzReadCurrentFile :
if (err==Z_OK) return iRead; The problem is it returns the size of the uncompressed file (300937 bytes) in ZRESULT TUnzip::Unzip , which believes there still something to read there :
if (res>0) return ZR_MORE; Just replace this line at the end of int unzReadCurrentFile from :
if (err==Z_OK) return iRead; to
if (err==Z_OK) return pfile_in_zip_read_info->rest_read_uncompressed; So if there REALLY still something to read, the return code will be correct (ZR_MORE), and UNZ_EOF (==0) if there is nothing more left to be read...
But I cannot understand why the zipped CAB file is not correctly unstreamed (doesn't last with a Z_STREAM_END code from 'inflate' but Z_OK instead) :/ I'm still puzzled on this one.
And no, the zlib is far from being well tested, the ZIP_MEMORY handle was specificaly said to be particulary UNTESTED ! It ALWAYS fails if the size of the buffer doesn't match to the size of the uncompressed file (iRead==len), especially on larger buffers which should normally handle file of thiner size. There is plenty of such tricks in the code which turns some particular cases into debuging hell...
Kochise
In Code we trust !
|
|
|
|
|
And just to stop moaning about how zlib is perfect and well tested, that I'm a moron so far, just read this :
http://www.eweek.com/article2/0,1895,1834632,00.asp
Reproduced here for archiving :
"A serious security flaw has been identified in Zlib, a widely used data compression library. Fixes have begun to appear, but a large number of programs could be affected.
Zlib is a data compression library that is used by many third-party programs and is distributed with many operating systems, including many Linux and BSD distributions.
Microsoft Corp. and other proprietary software companies also use the library in many programs. These companies can do so because Zlib is licensed under liberal BSD-style license.
This isn't the first time that the popular Zlib has been the center of a security concern. In 2002, a problem with how it handled memory allocation became a major concern.
This time, the flaw is a buffer overflow in the decompression process. Because the program doesn't properly validate input data, it can be fed bad data, which can lead to a buffer overflow.
This, in turn, means that if a user opens a file with a Zlib-enabled application, such as a Web browser or data compression tool, which contains specially malformed compressed data, an attacker could execute arbitrary code as the user. If this user were running as a system administrator the flaw would run at that level as well.
Read details here about open-source security tools on view at InfoSec.
The flaw was discovered by Tavis Ormandy of the Gentoo Linux Security Audit Team.
Since Zlib is so ubiquitous, this represents a serious security concern.
It's not clear how many programs are affected, but some operating system distributions are widely exposed. According to one source, numerous key packages in the Fedora Core 3 distribution use Zlib. Symantec Corp. reports that AIX, Debian, FreeBSD, Gentoo, SuSE, Red Hat, Ubuntu and many other operating systems are affected.
Some versions of Microsoft's DirectX, FrontPage, Internet Explorer, Office, Visual Studio, Messenger and the Windows InstallShield program, among other programs, also use Zlib and are potentially vulnerable.
Microsoft is currently looking into what vulnerabilities may exist in its software because of the Zlib problem.
As Ormandy said, "Everything from the Linux kernel to OpenSSH, Mozilla and Internet Explorer makes use of Zlib, and any application that understands PNG [portable network graphics] image [format] is likely to use it."
Click here to read about vulnerabilities in two popular open-source projects, phpMyAdmin and phpBB.
If exploited, this flaw could lead to DoS (denial of service) attacks on the targeted machine. This buffer overflow could also be used to allow a hacker unaurhorized access to a system.
At this time, however, Symantec reports, there are no known exploits.
In the open-source operating systems, deploying application fixes for this problem will tend to be straightforward. That's because in these operating systems the Zlib library is usually linked dynamically to applications. Thus, simply updating the operating system with the new library will take care of the problem for most applications. On other systems, however, and even with some open-source applications, each application will need to be patched.
"Zlib is statically linked quite often, especially on non-Unix platforms such as Windows; however, on Linux, BSD and [similar operating systems] it's more conventional to use dynamic linking, especially as Zlib is so widely used on these platforms that it reduces lots of unnecessary duplication," explained Ormandy.
Activity at the Zlib development site has been sparse for some time, and the main developers seem to have moved on to other projects. We received no response to our attempts to contact the developers in time for this story.
However, Ormandy said, "Zlib is very mature and stable, so development is sporadic, but it's certainly not dead. Mark Adler [a Zlib co-author] responded to my report with a patch and an in-depth investigation and explanation within 24 hours, and I believe he expects to release a new version of Zlib very soon."
In the meantime, many open-source operating systems already have patches for the buffer problem. These include Debian, FreeBSD, Gentoo, SuSE and Ubuntu.
Check out eWEEK.com's Security Center for the latest security news, reviews and analysis. And for insights on security coverage around the Web, take a look at eWEEK.com Security Center Editor Larry Seltzer's Weblog."
Kochise
In Code we trust !
|
|
|
|
|
Firstly, I'd like to thank everyone involved in making this component - it was very easy to add to the application I'm working on, and it worked the first time I tried it (no debugging - how often does that happen!)
I ran Boundschecker and it reported reading uninitialized memory in XUnZip.cpp for the following lines:
Line 1171:<br />
NEEDBITS(j)<br />
<br />
Line 1545:<br />
NEEDBITS(t)<br />
<br />
Line 2898:<br />
int unzlocal_getByte(LUFILE *fin,int *pi)<br />
{ unsigned char c;<br />
int err = (int)lufread(&c, 1, 1, fin);<br />
if (err==1)<br />
{ *pi = (int)c; <-- here
Has else anyone encountered this?
Warren
|
|
|
|
|
I haven't used XUnzip as much as I have XZip, so I don't know if this is a serious problem. If you believe it is serious, let me know the details - does it happen with all files, just one file, etc. Does BC report this error with the sample app?
Best wishes,
Hans
|
|
|
|
|