|
|
Comments and Discussions
|
|
 |
|
Hello everyone,
first of all: thanks for this piece of code, it is really helpful and easy to use.
I unzipped a file containing subfolders. I noticed, that the function
void EnsureDirectory(const TCHAR *rootdir, const TCHAR *dir)
creates the subfolder structure in the current working directory as well as in the target folder. Those temporary directories are not cleaned up afterwards.
As a quick fix, I removed the CreateDirectory(cd,NULL) call.
My tests still run, everything gets extracted correctly.
Does anyone have a similar experience? Did I forget something?
[Edit]
My tests run, because I didn't expect the Unzip-function to create subfolders. I do this before I call Unzip, that's why it works.
However, rootdir is set to
GetCurrentDirectory(MAX_PATH,rootdir);
when opening the zipfile. It is used in
TUnzip::Unzip(...)
As a bugfix I removed the EnsureDirectoryMethod and create the subfolder structure before I call Unzip on an item.
Best regards,
Markus
P.S.
Environment: Windows7, VS2010 SP1
modified 14 Mar '13 - 3:49.
|
|
|
|
|
really useful,many thanks.
|
|
|
|
|
I've tried everything I can think of but I cannot get the logic to accept anything other than a lliteral as in "some file name" as input for a file to be added to a just created zip file. I have the full path and file name in a CString object and have tried several ways of specifying including (void *)&MyCString for the 3rd parameter of the ZipAdd() function but it always fails. Any idea?
oh well. Shortly after I posted the above I found the solution to my problem:
CString wcString = "Whatever the full path and file name happen to be";
Then:
wcString.GetBuffer() <-- as the 3rd paramter to ZipAdd() works.
Mike - typical white guy.
"Political correctness is a doctrine, fostered by a delusional, illogical minority, and rabidly promoted by an unscrupulous mainstream media, which holds forth the proposition that it is entirely possible to pick up a piece of sh*t by the clean end."
Thomas Mann - "Tolerance becomes a crime when applied to evil."
As American as: hot dogs, apple and Sarah Palin.
modified 21 Jan '13 - 13:52.
|
|
|
|
|
Hi guys,
Thanks for the code. I've tried it and has found and fixed 2 bugs:
1. In BOOL AddFolderContent(HZIP hZip, TCHAR* AbsolutePath, TCHAR* DirToAdd) (it didn't work):
I've fixed as follows:
//Duan fixed bug
CString stPath;
stPath = AbsolutePath;
stPath += RelativePathNewFileFound;
if (ZipAdd(hZip, RelativePathNewFileFound, /*RelativePathNewFileFound*/(TCHAR*)((LPCTSTR)stPath), 0, ZIP_FILENAME) != ZR_OK)
{
return FALSE;
}
2. Bug for Unicode mode for adding a folder in a zip: In ZRESULT ZipAdd(HZIP hz, const TCHAR *dstzn, void *src, unsigned int len, DWORD flags)
I've fixed as follows:
//Duan added || flags == ZIP_FOLDER
if (flags == ZIP_FILENAME || flags == ZIP_FOLDER)
{
char szDest[MAX_PATH*2];
memset(szDest, 0, sizeof(szDest));
#ifdef _UNICODE
// need to convert Unicode dest to ANSI
int nActualChars = WideCharToMultiByte(CP_ACP, // code page
0, // performance and mapping flags
(LPCWSTR) dstzn, // wide-character string
-1, // number of chars in string
szDest, // buffer for new string
MAX_PATH*2-2, // size of buffer
NULL, // default for unmappable chars
NULL); // set when default char used
if (nActualChars == 0)
return ZR_ARGS;
#else
strcpy(szDest, dstzn);
#endif
lasterrorZ = zip->Add(szDest, src, len, flags);
}
else
{
lasterrorZ = zip->Add((char *)dstzn, src, len, flags);
}
Best Regards,
Duan.
|
|
|
|
|
Windows system using this code find subdirectory file didn't work
FindZipItem(hz, _T("toolbar\\bk.bmp"), true, &i, &ze)
change code，work well
int unzLocateFile (unzFile file, const TCHAR *szFileName, int iCaseSensitivity)
{
unz_s* s;
int err;
uLong num_fileSaved;
uLong pos_in_central_dirSaved;
if (file==NULL)
return UNZ_PARAMERROR;
if (_tcslen(szFileName)>=UNZ_MAXFILENAMEINZIP)
return UNZ_PARAMERROR;
char szFileNameA[MAX_PATH];
#ifdef _UNICODE
GetAnsiFileName(szFileName, szFileNameA, MAX_PATH-1);
#else
strcpy(szFileNameA, szFileName);
#endif
int iLen=strlen(szFileNameA);
for (int i=0;i<iLen;i++)
{
if (szFileNameA[i]=='\\')
{
szFileNameA[i]='/';
}
}
s=(unz_s*)file;
if (!s->current_file_ok)
return UNZ_END_OF_LIST_OF_FILE;
num_fileSaved = s->num_file;
pos_in_central_dirSaved = s->pos_in_central_dir;
err = unzGoToFirstFile(file);
while (err == UNZ_OK)
{
char szCurrentFileName[UNZ_MAXFILENAMEINZIP+1];
unzGetCurrentFileInfo(file,NULL,
szCurrentFileName,sizeof(szCurrentFileName)-1,
NULL,0,NULL,0);
TRACE(_T("%s\t%s"),szCurrentFileName,szFileNameA);
if (unzStringFileNameCompare(szCurrentFileName,szFileNameA,iCaseSensitivity)==0)
return UNZ_OK;
err = unzGoToNextFile(file);
}
s->num_file = num_fileSaved ;
s->pos_in_central_dir = pos_in_central_dirSaved ;
return err;
}
modified 9 Apr '12 - 7:33.
|
|
|
|
|
I found a small bug where the file date and time is not correctly set in unzipped file.
Some zip files do not set the date/time of their contained files at all.
So DOS date / time members are zero.
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);
ze->atime=ft; ze->ctime=ft; ze->mtime=ft;
.
.
.
}
DosDateTimeToFileTime fails if dostime and and dosdate is zero.
since ft is not initialized, some random values are inside.
Better:
Initialize ft with current date time.
ZRESULT TUnzip::Get(int index,ZIPENTRY *ze)
{ .
.
WORD dostime = (WORD)(ufi.dosDate&0xFFFF);
WORD dosdate = (WORD)((ufi.dosDate>>16)&0xFFFF);
FILETIME ft;
SYSTEMTIME st;
GetSystemTime(&st); SystemTimeToFileTime(&st, &ft);
DosDateTimeToFileTime(dosdate,dostime,&ft);
ze->atime=ft; ze->ctime=ft; ze->mtime=ft;
.
.
.
}
but anyway: Thanks for sharing the code!
With best regards,
Frank Kobs
Palette CAD GmbH
|
|
|
|
|
UnzipItem may create wrongly read-only files.
I'm calling the function like this:
zr = UnzipItem(hz, index, targetname, 0, ZIP_FILENAME);
The problem occurs when working with zip files, that have not been created with XZip.
For example, I have created zip files with
- Windows-7 Context menu 'Send To' 'Compressed (zipped) Folder'
- Java
- Total Commander 7.56a
- 7-Zip 9.20
In all cases UnzipItem creates wrongly read-only files.
The problem is located in TUnzip::Get when evaluating the so called upper half of the attribute value, which is called standard unix attr in the comment.
In the line, that initializes bool uwritable, what does this comment // ***hd*** mean? Does it mean Hans Dietrich?
I have temporary solved this issue for my use case by commenting out the evaluation of uwritable
, but I guess this won't work, if I would handle zip files that have been created on a unix machine.
Please advice, any comments are welcome.
I've already posted this issue in 2003, the problem still exist in the latest Version 1.3.
http://www.codeproject.com/Messages/681420/Problem-in-TUnzip-Get-gt-creates-sometimes-read-on.aspx[^]
Thomas Haase
|
|
|
|
|
Generally I don't like to hide warnings by using a global pragma. But I know, this is my personal preference.
But I would like to discuss an alternative solution.
In the past we had solved the related issue by by using _stricmp and _tzset instead of stricmp and tzset.
Are there any arguments against this alternative solution?
Thomas Haase
|
|
|
|
|
There has been a lot of fixes and enhancements posted over the years. Is there an updated version that includes all of these fixes?
|
|
|
|
|
Yes! Version 1.4 would be very welcome!
Thomas Haase
|
|
|
|
|
|
|
 General  News  Suggestion  Question  Bug  Answer  Joke  Rant  Admin
|
XZip and XUnzip provide non-MFC functions to create a zip, add files to it, and extract files from it - all in two .cpp files
| Type | Article |
| Licence | CPOL |
| First Posted | 13 May 2003 |
| Views | 407,036 |
| Downloads | 10,382 |
| Bookmarked | 239 times |
|
|
Submit an article or tip
Post your Blog
