|
Thanks.
The problem is not the desire to update the class, but the fact that the original code is such a horrible spaghetti mess that almost any change will break something else.
|
|
|
|
|
im finding that out the hard way lol
bear in mind this is no 2 line hello world example
i don't care what anyone else says..
its impressive and i appreciate the effort put into this code !
i posted again because im struggling with the unzip to memory ZR_MORE bug
its driving me nuts, i still can't really see where things go wrong.
since im aware of the issue i can work around the problem but im still
searching for a proper fix..
i keep running through unzReadCurrentFile with the visual studio debugger
trying to see why re calling Unzipitem again fixs the issue..
what i've done is this.. (notice the 2nd unzip call with len=1 to get the ZR_OK set)
HZIP hj = OpenZip( theConfig.m_sNewAppJarPath, 0, ZIP_FILENAME );
if ( hj )
{
ZIPENTRY ze;
memset( &ze, 0, sizeof(ze) );
int idx = -1;
ZRESULT fz = FindZipItem( hj, "META-INF/MANIFEST.MF", TRUE, &idx, &ze );
if ( fz == ZR_OK )
{
uBufferSize = ze.unc_size;
pBuffer = (char*)malloc( ze.unc_size );
ZRESULT zr = UnzipItem( hj, idx, pBuffer, uBufferSize, ZIP_MEMORY );
if ( zr == ZR_MORE )
{
Trace( WA, __FUNCTION__, "Unpack Manifest.mf ZR_MORE Bug Detected - Fixing.." );
zr = UnzipItem( hj, idx, pBuffer, 1, ZIP_MEMORY );
}
if ( zr != ZR_OK )
{
Trace( ER, __FUNCTION__, "Unpack Manifest.mf Problem Detected - Code: %08X", zr );
return NULL;
}
}
else if ( fz == ZR_NOTFOUND )
{
Trace( ER, __FUNCTION__, "Manifest.mf Could Not Be Found" );
return NULL;
}
else
{
Trace( ER, __FUNCTION__, "Find Manifest.mf Problem Detected - Code: %08X", fz );
return NULL;
}
CloseZip( hj );
}
something is obviously broken in unzReadCurrentFile and there has to be a proper solution ?
and a solution that will work for ZIP_MEMORY and ZIP_FILENAME etc
|
|
|
|
|
I made changes to the function AddFolderContent in xzip.cpp i figured i'd share.
Havn't tested this a lot yet but so far it seems ok..
First off i made changes because because i didn't like the way AddFolderContent worked.
What i did was change how it names content in the .zip
BOOL AddFolderContent( HZIP hZip, TCHAR* AbsolutePath, TCHAR* DirToAdd )
normaly DirToAdd is added into the zip file and all its contents aswell.
so what i wanted was to add the contents and directory structure to a zip
with out adding the selected DirToAdd folder into the zip.
so this will do the same thing except the DirAdd folder will NOT be added to the zip.
Also before i carry on I'd like to say thank you to all the contributors, i appreciate all the effort people !
so here is the complete function after my changes (note: usage remains the same)
i pulled out some logging code if anyone is wondering why i added so many brackets ?
BOOL AddFolderContent( HZIP hZip, TCHAR* AbsolutePath, TCHAR* DirToAdd )
{
HANDLE hFind;
WIN32_FIND_DATA FindFileData;
TCHAR PathToSearchInto [MAX_PATH] = {0};
_tcscpy(PathToSearchInto, AbsolutePath);
_tcscat(PathToSearchInto, _T("\\"));
_tcscat(PathToSearchInto, DirToAdd);
_tcscat(PathToSearchInto, _T("\\*"));
hFind = FindFirstFile(PathToSearchInto,&FindFileData);
if(hFind == INVALID_HANDLE_VALUE)
{
return FALSE;
}
bool bSearch = true;
while(bSearch)
{
if(FindNextFile(hFind,&FindFileData))
{
if ( (_tcscmp(FindFileData.cFileName, _T(".")) == 0) || (_tcscmp(FindFileData.cFileName, _T("..")) == 0) )
continue;
if((FindFileData.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY))
{
TCHAR RelativePathNewDirFound[MAX_PATH] = {0};
_tcscat(RelativePathNewDirFound, DirToAdd);
_tcscat(RelativePathNewDirFound, _T("\\"));
_tcscat(RelativePathNewDirFound, FindFileData.cFileName);
if (AddFolderContent(hZip, AbsolutePath, RelativePathNewDirFound)== FALSE)
{
return FALSE ;
}
}
else
{
TCHAR RelativePathNewFileFound[MAX_PATH] = {0};
_tcscpy(RelativePathNewFileFound, DirToAdd);
_tcscat(RelativePathNewFileFound, _T("\\"));
_tcscat(RelativePathNewFileFound, FindFileData.cFileName);
char* ptr1 = strchr( RelativePathNewFileFound, '\\' );
char* ptr2;
if ( ptr1[0] == 0x5C )
{
ptr2 = strchr( ptr1, ptr1[1] );
}
if ( ZipAdd( hZip, ptr2, RelativePathNewFileFound, 0, ZIP_FILENAME) != ZR_OK )
{
return FALSE;
}
}
}
else
{
if(GetLastError() == ERROR_NO_MORE_FILES)
{
bSearch = false;
}
else
{
FindClose(hFind);
return FALSE;
}
}
}
FindClose(hFind);
return true;
}
|
|
|
|
|
This is excellent, and I appreciate your willingness to share.
Two questions:
1. Did you run the tests in the demo for this code?
2. I haven't had a chance to look at this in detail, but I will post your version - with credit to you - if you would like me to. Is this acceptable? If yes, please send me zip (do not include .exe) of complete project with your changes. Make whatever changes to file headers you think appropriate. Send zip to me at hdietrich at gmail dot com.
|
|
|
|
|
Lots of respect to you Hans, i am no professional programmer
but im a 35yr old guy who likes to work on projects as a hobby
and im making a Hack Tool for an LG Cell Phone and have used the zip
code to extract & write files to .JAR files. My tool rebuilds a databse
and reformats content for the purpose of adding apps to LG cell phones.
Last night i did a bit of searching on the Host OS stated in the Zip header
and i changed my code to mimic the same OS & ver as reported when making a zip with winrar.
I think it may be interesting to a #define or something to the header so the coder can
select what host/version he wants in his zips
in TZip::Add i changed the following,
zfi.vem = (ush)0x0014;
zfi.ver = (ush)20;
That will show in winrar info box that the archive is DOS 2.0 and not windows 2.0
Here is a chart i found on the net about this issue..
also im not sure it makes any difference anyway lol
PkZip Host OS table
0 - MS-DOS and OS/2 (FAT)
1 - Amiga
2 - VMS
3 - *nix
4 - VM/CMS
5 - Atari ST
6 - OS/2 1.2 extended file sys
7 - Macintosh
8-255 - unused
*/
I've made my own source mod many years ago and i noticed THIS code is still currently
beeing used by VALVE inc. in all their source based games but they are using ver 1.0 of the code
Just an interesting observation i figured most people wouldn't know.
I highly suggest warning people somewhere in the documentation that you can NOT
call OpenZip and the AddZip with the same handle, i find that a sad limitation in this code
in an otherwise very impressive package of code.
Im working on mod'ing AddFolderContent right now to return the num of items written
that way you can use the return result to validate zip creation etc
(its almost done just having probs getting folders counted)
Lastly i will try running your test code Hans i didnt think of that, good idea (i seen it / i know what you mean)
and if i can help out at all then ya for sure ill do what i can to share my changes..
|
|
|
|
|
so this is what i've done so far to AddFolderContent
to use this you have to add the following line to XZIP.cpp
extern int NumFilesAdded = 0;
It will have to be added up high enough so CloseZip can use it.
Then add NumFilesAdded = 0; to CloseZipZ as shown below.
ZRESULT CloseZipZ(HZIP hz)
{ if (hz==0) {lasterrorZ=ZR_ARGS;return ZR_ARGS;}
TZipHandleData *han = (TZipHandleData*)hz;
if (han->flag!=2) {lasterrorZ=ZR_ZMODE;return ZR_ZMODE;}
TZip *zip = han->zip;
lasterrorZ = zip->Close();
delete zip;
delete han;
NumFilesAdded = 0;
return lasterrorZ;
}
Then change the function to the version i pasted below.
Change return type in header from BOOL to int also.
int AddFolderContent( HZIP hZip, TCHAR* AbsolutePath, TCHAR* DirToAdd )
{
HANDLE hFind;
WIN32_FIND_DATA FindFileData;
TCHAR PathToSearchInto [MAX_PATH] = {0};
_tcscpy(PathToSearchInto, AbsolutePath);
_tcscat(PathToSearchInto, _T("\\"));
_tcscat(PathToSearchInto, DirToAdd);
_tcscat(PathToSearchInto, _T("\\*"));
hFind = FindFirstFile(PathToSearchInto,&FindFileData);
if(hFind == INVALID_HANDLE_VALUE)
{
return FALSE;
}
bool bSearch = true;
while(bSearch)
{
if(FindNextFile(hFind,&FindFileData))
{
if ( (_tcscmp(FindFileData.cFileName, _T(".")) == 0) || (_tcscmp(FindFileData.cFileName, _T("..")) == 0) )
continue;
if ( FindFileData.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY )
{
TCHAR RelativePathNewDirFound[MAX_PATH] = {0};
_tcscat(RelativePathNewDirFound, DirToAdd);
_tcscat(RelativePathNewDirFound, _T("\\"));
_tcscat(RelativePathNewDirFound, FindFileData.cFileName);
if ( AddFolderContent(hZip, AbsolutePath, RelativePathNewDirFound) == FALSE )
{
return FALSE ;
}
}
else
{
TCHAR RelativePathNewFileFound[MAX_PATH] = {0};
_tcscpy(RelativePathNewFileFound, DirToAdd);
_tcscat(RelativePathNewFileFound, _T("\\"));
_tcscat(RelativePathNewFileFound, FindFileData.cFileName);
char* ptr1 = strchr( RelativePathNewFileFound, '\\' );
char* ptr2;
if ( ptr1[0] == 0x5C )
{
ptr2 = strchr( ptr1, ptr1[1] );
}
if ( ZipAdd(hZip, ptr2, RelativePathNewFileFound, 0, ZIP_FILENAME) != ZR_OK )
{
return false;
}
else
{
NumFilesAdded += 1;
}
}
}
else
{
if ( GetLastError() == ERROR_NO_MORE_FILES )
{
bSearch = false;
}
else
{
FindClose(hFind);
return false;
}
}
}
FindClose(hFind);
return NumFilesAdded;
}
i created a function in my program that shows how i'd create a zip from a folder
and then verify the number of items added..
int CDatabaseTools::CreateJar( void* Jar, char* szPath, char* szDirectory )
{
HZIP hz = CreateZip( Jar, 0, ZIP_FILENAME );
int res = AddFolderContent( hz, szPath, szDirectory );
CloseZip( hz );
ZIPENTRY ze;
memset( &ze, 0, sizeof(ze) );
HZIP hj = OpenZip( Jar, 0, ZIP_FILENAME );
GetZipItem( hj, -1, &ze );
CloseZip( hj );
int numitems = ze.index;
if ( res != numitems )
{
Trace( ER, __FUNCTION__, "Zip Verification Failed" );
return 1;
}
else
{
Trace( ZP, __FUNCTION__, "Zip Verified" );
return 0;
}
}
and finally here is how i called my new function in my mfc app..
void CPPgKeybo2::OnBnClickedButton2()
{
int res = theDatabaseTools.CreateJar( "D:\\LG Mobile Tools\\Test.jar", "D:\\LG Mobile Tools", "tmp" );
if ( res != 0 )
{
Trace( ER, __FUNCTION__, "Create New .Jar Failed" );
}
else
{
Trace( ZP, __FUNCTION__, "Create New .Jar Succeeded" );
}
}
|
|
|
|
|
TUnzip::Unzip creates read only files, i don't know if this was intended by i find it very lame !
so i made a quick fix i figured i'd share.. change the line in Unzip like below,
From:
h = ::CreateFile((const TCHAR*)dst, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, ze.attr, NULL);
To:
h = ::CreateFile((const TCHAR*)dst, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
Also i can't believe this is ANOTHER zip class that supports almost everything except
adding a single file to an existing zip LOL that just blows me away !
And just to confuse the hell out of everyone the extensive code comments deliberatly avoid touching on the subject,
leaving the users to post on here, why ? why can't i .. etc
The least that could have been done is add a warning in the page about it if it can't be mentioned in the code.
Sorry but that really ticked me off because i keep finding the same issue with other similar zip projects
and this was the 3rd in a row that was missing that feature AND seemed to forget to mention..
YOU CAN'T ADD FILES TO ZIP's ..unless you create one yourself first <rolleyes>
normaly i staticly link to zlib but was hoping for an easier alternative..
oh.. and if i get UPDATING zip's working I will post my fix for everyone else too
|
|
|
|
|
this read only fix i posted doesn't always work. it seemed to work at first but
after trying many different zip files i found in some cases you would get nothing
but an empty file with no error reported..
so.. couple years back someone posted that you change the create attribute to the following,
ze.attr ^= FILE_ATTRIBUTE_READONLY
now i have not tested this at all but i am concerned that if you did want a file
to be extracted as read only this other fix would make that impossible.
now i dont know very much about the zip format but i did a quick test with winrar..
i made a file read-only and zip'd it then extracted it to a new folder and
the newly created/extracted file WAS extracted out preserving the read-only attribute.
my point ? i think that other guys fix would break an intended feature..
so i did some debugging to follow along what was happening in xunzip.cpp when the attributes get set
and the problem has nothing to do with reading or setting the read only attribute (best i can tell)
The problem is actualy in the below code..
bool uwriteable= (a&0x00800000)!=0;
if (!uwriteable||wreadonly) ze->attr|=FILE_ATTRIBUTE_READONLY;
uwriteable is getting set FALSE when it should be set to TRUE
so what i did was change the block of code that line is found at and
set the originaly modified line i posted before back to its original form as shown below..
h = ::CreateFile((const TCHAR*)dst, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, ze.attr, NULL);
the following code is what i changed basicly ( found in TUnzip::Get )
unsigned long a = ufi.external_fa;
bool uisdir = ( a&0x40000000 ) != 0;
bool wreadonly = ( a&0x00000001 ) != 0;
bool whidden = ( a&0x00000002 ) != 0;
bool wsystem = ( a&0x00000004 ) != 0;
bool wisdir = ( a&0x00000010 ) != 0;
bool warchive = ( a&0x00000020 ) != 0;
ze->attr=FILE_ATTRIBUTE_NORMAL;
if ( uisdir || wisdir ) ze->attr |= FILE_ATTRIBUTE_DIRECTORY;
if ( warchive ) ze->attr |= FILE_ATTRIBUTE_ARCHIVE;
if ( whidden ) ze->attr |= FILE_ATTRIBUTE_HIDDEN;
if ( wreadonly ) ze->attr |= FILE_ATTRIBUTE_READONLY;
if ( wsystem ) ze->attr |= FILE_ATTRIBUTE_SYSTEM;
This change (i removed the uwritable check) should hopefully solve the files beeing created read only problem
UNLESS they are SUPPOSE to be extracted as read only.
And im not sure why yet this is happening, if its because some files are simply
missing unix attributes or if the code is simply interpeting the found data incorrectly ?
someone smarter wants to fix this ? i'd look in the below call..
unzlocal_GetCurrentFileInfoInternal calls unzlocal_getLong(s->file,&file_info.external_fa)
|
|
|
|
|
Thanks, I will look at this.
|
|
|
|
|
If a file is added to a ZIP, that contains non ANSI chars in its name, these characters are
garbled in the ZIP. This ist because
ZRESULT ZipAdd(HZIP hz, const TCHAR *dstzn, void *src, unsigned int len, DWORD flags)
converts the widechar name to char using the ANSI codepage:
WideCharToMultiByte(CP_ACP,..)
This is wrong. According to the ZIP specs the DOS US codepage is used. You have to use
CP_OEMCP instead of CP_ACP.
Besides this (as I posted earlier) the conversion has to be done for file- and for
directory-names. So this is my fixed version:
ZRESULT ZipAdd(HZIP hz, const TCHAR *dstzn, void *src, unsigned int len, DWORD flags)
{
if (hz == 0)
{
lasterrorZ = ZR_ARGS;
return ZR_ARGS;
}
TZipHandleData *han = (TZipHandleData*)hz;
if (han->flag != 2)
{
lasterrorZ = ZR_ZMODE;
return ZR_ZMODE;
}
TZip *zip = han->zip;
char szDest[MAX_PATH*2];
memset(szDest, 0, sizeof(szDest));
#ifdef _UNICODE
int nActualChars = WideCharToMultiByte(CP_OEMCP,
0,
(LPCWSTR) dstzn,
-1,
szDest,
MAX_PATH*2-2,
NULL,
NULL);
if (nActualChars == 0)
return ZR_ARGS;
#else
strcpy(szDest, dstzn);
#endif
if (flags == ZIP_FILENAME)
{
lasterrorZ = zip->Add(szDest, src, len, flags);
}
else
{
lasterrorZ = zip->Add(szDest, src, len, flags);
}
return lasterrorZ;
}
Note: This fix will only work for chars within the DOS-US codepage. If filenames conatain other Unicode chars
all names must be converted to UTF-8 and bit 11 of the "general purpose bit flag" must be set. (Not implemented)
See ZIP specs for details.
|
|
|
|
|
For CP_OEMCP (in my case CP866) to work with WinRAR, you need to change line in function TZip::Add from
zfi.vem = (ush)0xB17;
to
zfi.vem = (ush)20;
|
|
|
|
|
|
I recently reached the same situation as you . I also took a quick look at the code and I finally figured out a way to use it without modifying anything in the unzip code.
I do call UnzipItem() with the proper buffer size, according to the uncompress size obtained with GetZipItem(). The file gets uncompressed at that time but ZR_MORE error code is returned. I then call again UnzipItem with 1 byte buffer. It returns OK at that time, confirming that there was nothing else to unzip for that file.
I tried it with buffers of various lengths and various contents and I got successful results . Included is a part of the code used to perform the tests.
Hoping its gonna help others...
TiL_MtL
#define BUFLENBIG 40000
void Tst(char* pBuf, int len)
{
ZRESULT lZErr;
void* lZipBuf;
unsigned long lZipLen;
ZIPENTRY lZEntry;
char lZipFile[BUFLENBIG];
char lUnzipFile[BUFLENBIG];
char lDummy;
HZIP lZH = CreateZip(lZipFile, BUFLENBIG, ZIP_MEMORY);
ASSERT(lZH != NULL);
lZErr = ZipAdd(lZH, "1", pBuf, len, ZIP_MEMORY);
ASSERT(lZErr == ZR_OK);
lZErr = ZipGetMemory(lZH, &lZipBuf, &lZipLen);
ASSERT(lZErr == ZR_OK);
ASSERT(lZipBuf == lZipFile);
lZErr = CloseZip(lZH);
ASSERT(lZErr == ZR_OK);
HZIP lZH2 = OpenZip(lZipBuf, lZipLen, ZIP_MEMORY);
ASSERT(lZH2 != NULL);
lZErr = GetZipItem(lZH2, 0, &lZEntry);
ASSERT(lZErr == ZR_OK);
ASSERT(lZEntry.unc_size == len);
lZErr = UnzipItem(lZH2, 0, lUnzipFile, lZEntry.unc_size, ZIP_MEMORY);
ASSERT(lZErr == ZR_MORE);
lZErr = UnzipItem(lZH2, 0, &lDummy, 1, ZIP_MEMORY);
ASSERT(lZErr == ZR_OK);
lZErr = CloseZip(lZH2);
ASSERT(lZErr == ZR_OK);
ASSERT(memcmp(lUnzipFile, pBuf, len) == 0);
}
|
|
|
|
|
Hello,
first of all...this code is a great thing, but i wonder how to use all the stuff written on Unix too.
At the moment i develop a small project with QtCreator on windows, but the source is completely windows independant and can be compiled on Unix without any code changes. And maybe some of the ppl here had same problems and created a source package with all needed changes?
Otherwise i bite the bullet and work out a solution by myself (why to reinvent the wheel ^^)
so long
Sebastian
|
|
|
|
|
Hi, is there a way to show a progress to the user when a lengthy compression operation is happening? May be a callback function?
|
|
|
|
|
Yes, this has been suggested before. I will try to add it,
|
|
|
|
|
It seems current version has bug for filetime setting,
if files are zipped by XZip, everything goes well,
'cause XZip save CTime ,ATime and MTime in its extra data field.
but some other zip tools do not,
they just use last mod file time/date in file header,
when XZip unzip files zipped by other tools,
filetimes will be wrong,especially for MTime,
I think it's a most important time for a file.
Following codes may clear this,
I have tested only on NTFS,FAT not yet,please confirm it.
ZRESULT TUnzip::Get(int index,ZIPENTRY *ze)
WORD dostime = (WORD)(ufi.dosDate&0xFFFF);
WORD dosdate = (WORD)((ufi.dosDate>>16)&0xFFFF);
FILETIME ft;
DosDateTimeToFileTime(dosdate,dostime,&ft);
FILETIME utcft;
LocalFileTimeToFileTime(&ft,&utcft);
ze->atime=utcft; ze->ctime=utcft; ze->mtime=utcft;
|
|
|
|
|
Hello,
Do you know that library almost works on Windows mobile. Parts that need to be altered are: setting file time and reading / writing to files. On WM calls like:
CreateFile((const TCHAR*)dst, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS,
ze.attr, NULL);
can cause trouble especially when unziping to storage cards. They can successfully be replaced with std calls. For example I replaced that one with std::ofstream .
For file time I have no suggestions.
BTW, thanks for sharing this.
Velja Radenkovic
www.lusys.net
|
|
|
|
|
Hi Hans,
Thanks for posting this sample - looks like it could be useful.
You may (or may not) already know of this, but when you compile an x64 build (with VC++ 2005), you get the following error:
crtdefs.h(543) : fatal error C1189: #error : You cannot use 32-bit time_t (_USE_32BIT_TIME_T) with _WIN64
I have not tried to diagnose this - just though you might want know.
Thanks,
- Dale
|
|
|
|
|
This is what I did to get XUnzip.cpp to compile under Visual Studio 2010:
1. Comment out the #define _USE_32BIT_TIME_T
2. Cast to __time32_t where appropriate (wherever there's a 4-byte time value)
if (hasmtime)
{ time_t mtime = *(__time32_t*)(extra+epos); epos+=4;
ze->mtime = timet2filetime(mtime);
}
if (hasatime)
{ time_t atime = *(__time32_t*)(extra+epos); epos+=4;
ze->atime = timet2filetime(atime);
}
if (hasctime)
{ time_t ctime = *(__time32_t*)(extra+epos);
ze->ctime = timet2filetime(ctime);
}
Haven't tested this thoroughly so use at your own risk!
Eric
|
|
|
|
|
I ran into the same problem. This ist my solution:
1.) Skip #define _USE_32BIT_TIME_T for 64-Bit builds:
#ifndef _WIN64
#define _USE_32BIT_TIME_T //+++1.2
#endif
2.) Change time_t and time functions to the explicit 32-Bit versions:
time_t ---> __time32_t
mktime(&tm) ---> _mktime32(&tm)
gmtime(&timer) ---> _gmtime32(&timer);
This seems to work fine. But I haven't test it thoroughly yet.
|
|
|
|
|
I have tested this solution too, and it seems to work well.
Anyway, I would prefer an 'official' solution in 'Version 1.4'.
Thomas Haase
|
|
|
|
|
would be nice - but not work with filesize over 4gb ...
sascha
|
|
|
|
|
Great work .
But there's a bug in the UNICODE build:
ZRESULT ZipAdd(HZIP hz, const TCHAR *dstzn, void *src, unsigned int len, DWORD flags)
does the WideCharToMultiByte() conversion only for flags == ZIP_FILENAME . So it fails in AddFolderContent() where it is called with flags==ZIP_FOLDER .
I think it should be like this:
ZRESULT ZipAdd(HZIP hz, const TCHAR *dstzn, void *src, unsigned int len, DWORD flags)
{
if (hz == 0)
{
lasterrorZ = ZR_ARGS;
return ZR_ARGS;
}
TZipHandleData *han = (TZipHandleData*)hz;
if (han->flag != 2)
{
lasterrorZ = ZR_ZMODE;
return ZR_ZMODE;
}
TZip *zip = han->zip;
char szDest[MAX_PATH*2];
memset(szDest, 0, sizeof(szDest));
#ifdef _UNICODE
int nActualChars = WideCharToMultiByte(CP_ACP,
0,
(LPCWSTR) dstzn,
-1,
szDest,
MAX_PATH*2-2,
NULL,
NULL);
if (nActualChars == 0)
return ZR_ARGS;
#else
strcpy(szDest, dstzn);
#endif
if (flags == ZIP_FILENAME)
lasterrorZ = zip->Add(szDest, src, len, flags);
else
lasterrorZ = zip->Add(szDest, src, len, flags);
return lasterrorZ;
}
|
|
|
|
|
Hello,
how can i show progress while creating the zip-file?
cause biger files (100mb) take long time to zip...
thanks!
|
|
|
|
|