 |
|
|
Hi, all.
I am not quite familiar with the "Creative Common Attribution-ShareAlike 2.5 Generic" license, so I don't know whether it's OK to use this wrapper in commercial software.
Is it right that if I use it in commercial software, I must not change the code in it?
Thanks.
|
|
|
|
|
|
|
Yes, I give you full permission to use this code for _any_ purpose. And to modify it.
|
|
|
|
|
|
|
In two places, you check for a ":" to see if a path is relative or not. But that gave the wrong result on a UNC path, eg
\\Server\directory\file.txt
So, I changed PrepareSourcePath to:
void CZipper::PrepareSourcePath(LPTSTR szPath)
{
if (PathIsUNC (szPath)) return;
bool bFullPath = (strchr(szPath, ':') != NULL);
if (!bFullPath)
{
char szTemp[MAX_PATH];
lstrcpy(szTemp, szPath);
_makepath(szPath, NULL, m_szRootFolder, szTemp, NULL);
}
}
and changed CZipper::AddFileToZip similarly...
bool bFullPath = (strchr(szFilePath, ':') != NULL);
if (::PathIsUNC (szFilePath))
bFullPath = true;
I hope that helps others!
Iain.
I am one of "those foreigners coming over here and stealing our jobs". Yay me!
|
|
|
|
|
|
|
This may not be the best way of fixing this but I solved the problem of making it all work in a Unicode app. by making the problem go away. 
First of all, we had previously taken the Zipper/Unzipper and ZLib code and built it into a static library, so we're not quite starting from the same place. I am still building this as a MultiByte character set library and just using it in my Unicode app.
The problem then is that when the headers are included in your Unicode app. all the LPTSTR declarations change into LPWSTR and so on. Then your app. won't link because it can't find the LPWSTR versions of the functions in the library (as they don't exist).
So, all I've done is change Zipper and Unzipper so that all the LPCTSTR function parameters are LPCSTR and all the LPTSTR ones are LPSTR and rebuilt the library (still using the Multibyte character set). Now that these parameters are all explicitly chars, not TCHARs, everything works fine so long as when you call the functions in your Unicode app. you are sure to pass char strings to the functions and not TCHARs.
The important thing to be aware of is that there is no need to convert everything to Unicode in a Unicode app. If you explicitly use char, LPSTR, LPCSTR and CStringA and don't use _T() macros then everything is exactly as it is in an MBCS build, even if you are building for Unicode.
Also, this approach is, of course, no use to you if you need to add files with Unicode names into your zip files, or save the zip file with a Unicode name. But it's good enough for my purposes.
Regards
- Roger
|
|
|
|
|
|
|
I have gotten around the unicode problem (at least compiling) but when I try to create a zip file, and then add a file into it (not the same path) the code returns success but the file is not created. What am I doing wrong? The file names and paths are showing up correct in my log file, but no file is created. Here is the code:
if (zipme.OpenZip(szTempOutput, NULL, TRUE))
{
fnLogServerEvent(m_pConnect, L"zip open", szTempOutput);
if (zipme.AddFileToZip(strPathFile, true))
fnLogServerEvent(m_pConnect, L"zip success", strPathFile);
else
fnLogServerEvent(m_pConnect, L"zip not successful", strPathFile);
}
else
fnLogServerEvent(m_pConnect, L"zip open not successful", szTempOutput);
The string used in the OpenZip is the full path and name (c:\temp\a.zip) and the file to be zipped is the same way (c:\mydir\myfile.txt)
As I have been struggling with this, it seems that the problem lies in the zipOpen statement in Zipper.c - from what I have read this must be using an fopen which only works with char, not wchar_. I think that may be my problem - the file is not really opening, even though it does not give me an error. Any ideas how to remedy this?
|
|
|
|
|
|
|
I am getting the following erros in both the Unzipper and Zipper files (more errors than I have posted here but all the same basic error):
I am not a C guru. I am working in VS6. Any help is most welcome!
Unzipper.cpp
C:\ina\Source Codes\INABusinessObject\Unzipper.cpp(50) : error C2664: 'UnzipTo' : cannot convert parameter 1 from 'char [261]' to 'const unsigned short *'
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
C:\ina\Source Codes\INABusinessObject\Unzipper.cpp(100) : error C2664: 'GetFullPathNameW' : cannot convert parameter 3 from 'char [260]' to 'unsigned short *'
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
C:\ina\Source Codes\INABusinessObject\Unzipper.cpp(123) : error C2664: 'lstrcpyW' : cannot convert parameter 1 from 'char [261]' to 'unsigned short *'
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
C:\ina\Source Codes\INABusinessObject\Unzipper.cpp(160) : error C2440: '=' : cannot convert from 'char [261]' to 'const unsigned short *'
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
C:\ina\Source Codes\INABusinessObject\Unzipper.cpp(190) : error C2664: 'lstrcmpiW' : cannot convert parameter 2 from 'char *' to 'const unsigned short *'
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
C:\ina\Source Codes\INABusinessObject\Unzipper.cpp(222) : error C2664: 'lstrcmpiW' : cannot convert parameter 2 from 'char *' to 'const unsigned short *'
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
C:\ina\Source Codes\INABusinessObject\Unzipper.cpp(257) : error C2664: 'lstrlenW' : cannot convert parameter 1 from 'char [261]' to 'const unsigned short *'
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
C:\ina\Source Codes\INABusinessObject\Unzipper.cpp(277) : error C2440: '=' : cannot convert from 'char [261]' to 'const unsigned short *'
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
Zipper.cpp
C:\ina\Source Codes\INABusinessObject\Zipper.cpp(52) : error C2664: '_splitpath' : cannot convert parameter 1 from 'const unsigned short *' to 'const char *'
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
|
|
|
|
|
|
|
Sounds like you might be compiling for UNICODE.
If so you will need to change all the string types/parameters to their wide-string equivalents.
|
|
|
|
|
|
|
it is so excellent , and I hope we can become friends.i'am a mfc beginner,so,i hope that you can help me . thank you 1!
my e-mail is: purefriendsky@live.cn
|
|
|
|
|
|
|
Thanks .dan.g. for your code.
I have made a vc++ 2005 version based on your vc++ 6.0 version. thank you.
I modified these:
1. replace char with wchar_t and responding string function.
2. comment
bool CZipper::AddFolderToZip(LPCTSTR szFolderPath, bool bIgnoreFilePath)
{
...
// folders are denoted by a trailing '\\'
// lstrcat(szFolderName, L"\\");
...
}
to avoid empty directory when to zip folder.
3. define ZLIB_WINAPI to avoid error like:
Unzipper.obj : error LNK2001: unresolved external symbol _unzOpenhello to all
|
|
|
|
|
|
|
If you send me the relevant zip files, I'll add them to the top of the article.
|
|
|
|
|
|
|
Compiling...
Unzipper.cpp
c:\projects\digene\hc2 v4.0\hc2 v4.0 source code\zlib\unzip.h(122) : error C2146: syntax error : missing ';' before identifier 'unzStringFileNameCompare'
c:\projects\digene\hc2 v4.0\hc2 v4.0 source code\zlib\unzip.h(122) : fatal error C1004: unexpected end of file found
This is a Visual C++ 6.0 MFC project, UNICODE.
Any suggestions?
|
|
|
|
|
|
|
Hello,
I need to re-build for Windows Vista 64 bit this library.
Do you someone have already approached this job.
Thanks in advantage
a.tess
|
|
|
|
|
|
|
I have one main folder with subfolders ".moc",".ui",".obj".
These are folders created during compilation one project in linux. Thus my folder structure will look like:
-->MainFolder
xx.pro
Makefile
xx.ui
xx.ui.h
-->.moc
-->a.cpp
-->b.cpp
-->.obj
-->a.o
-->b.o
-->.ui
-->a.ui
The problem is when I zipped this mainfolder to mainfolder.zip with CZipper and extracted the archieve, i got the output as;
-->MainFolder
xx.pro
Makefile
xx.ui
xx.ui.h
There is no .moc,.ui,.obj folders and their corresponding files!!!!!!
But when I zipped it with winzip, no problem with extraction and folders/files are exact match.
Do you have any idea of that?
How can I fix it in CZipper class?
|
|
|
|
|
|
|
I wanted to use the CZipper class with latest zlib (ver 1.2.3). In the process I came across two issues.
ISSUE #1: The constructor does not initialize m_uzFile to NULL. The existing code is as follows:
CZipper::CZipper(LPCTSTR szFilePath, LPCTSTR szRootFolder, bool bAppend) : m_uzFile(0)
{
CloseZip();
if (szFilePath)
OpenZip(szFilePath, szRootFolder, bAppend);
}
bool CZipper::CloseZip()
{
int nRet = m_uzFile ? zipClose(m_uzFile, NULL) : ZIP_OK;
...
}
Since m_uzFile is non-NULL zipClose(m_uzFile, NULL) is called and fails. An exception is thrown.
ONE SOLUTION #1:
Do not call CloseZip() in the constructor and initialize all member variables in the constructor. (I personally like to minimize function calls in constructors.)
ISSUE #2: Appending to an existing zip file overwrites the contents.
In CZipper::OpenZip() the following call is made with bAppend = true:
m_uzFile = zipOpen(szFullPath, bAppend ? 1 : 0).
RESULTS #2:
This deletes the existing zip file's contents and adds a new the file.
EXPECTED RESLUTS #2:
I expect the new file to be APPENDED to the zip file. The existing contents should remain.
SOLUTION #2:
I made the following change that seems to work:
m_uzFile = zipOpen(szFullPath, bAppend ? APPEND_STATUS_ADDINZIP : APPEND_STATUS_CREATE);
zip.h has the following definitions:
#define APPEND_STATUS_CREATE (0)
#define APPEND_STATUS_CREATEAFTER (1)
#define APPEND_STATUS_ADDINZIP (2)
APPEND_STATUS_ADDINZIP is used in zip.c to control the appending code. APPEND_STATUS_CREATEAFTER is never referenced.
Cheers!
|
|
|
|
|
|
|
I tried to use your lib with a UNICODE project, but I could not compile with it. May you help me for this
Thanks in advance
Thuy
|
|
|
|
|
|
|
I modified some codes, so that it can be used for a UNICODE program. Because the lib is fixed, it still can not be used for a UNICODE file name.
Any one need, pls contact me
|
|
|
|
|
|
|
A few weeks ago, I saw this nice code to wrap the ZLib/ZIP functionality in a comfortable way.
Nearly everything works fine to zip folders and their subfolders together in one zip file.
Only the XP unzipping feature has problems with subfolders in the zip files.
Double clicking a zip file in windows XP starts the Extraction Wizard and during decompression a password should be entered for all files in subfolders.
This behaviour does not appear while decompressing with other zip tools like WinZip or TotalCommander.
Can anyone reproduce this problem or has a solution?
Stefan Frank
|
|
|
|
|
|
|
I've found the source code which produces the problem.
In the method "CZipper::AddFolderToZip", the following code wants to generate a directory. I think this was a previous correction to store empty folders in the zip.
if (lstrlen(szFolderName))
{
int nRet = zipOpenNewFileInZip(m_uzFile,
szFolderName,
&zfi,
NULL,
0,
NULL,
0,
NULL,
Z_DEFLATED,
Z_DEFAULT_COMPRESSION);
zipCloseFileInZip(m_uzFile);
}
I've commented it out, because I don't want to store empty folders and then the XP unzipping feature does not make any problems.
Stefan Frank
|
|
|
|
|
|
|
Hi - I have been trying to use ZSEEK to set the file pointer as I need to "rewind" a bit, but without any luck. Does anyone have an example of how to do this?
Paul
|
|
|
|
|
|
|
Hi,
Firstly, let me say a big THANK YOU for the code. It is very easy to use and extremely useful, especially considering the ugly raw interface of zlib.
Now to business. I am using the latest version of the CZipper class (downloaded from www.abstractspoon.com) and I noticed some weird behaviour.
I have a collection of files and folders in the root directory of the zip file and while some programs (e.g. WinZip) can use the resulting zip files without any problems, other programs (e.g. Google Earth) cannot. [In case you are wondering, I use CZipper to create Google Earth KMZ archives]. After a lot of debugging and frustration, I realised that the problem lies with the _alphabetical_ ordering of the files and folders in the zip archive. To be more precise, this works:root/
|
|-- A/ => Folder A
|-- Z/ => Folder Z
|-- F => File F
This doesn't:root/
|
|-- A/ => Folder A
|-- B/ => Folder B
|-- F => File F
The difference is the name of the file and the alphabeticaly last folder. If the name of the file is alphabetically AFTER the name of the last folder, the archive is not usable by some aplications.
Before you rush to accuse Google Earth for this weird behaviour, I also unzipped the file and rezipped it with WinZip, in which case Google Earth was more than happy to load it. This all points to a problem in the CZipper class, but I have been unable to locate the source of the problem.
Any help will be greatly appreciated! Many thanks.
--
/stokos
|
|
|
|
|
|
|
Dan, Your code was really helpful
Think you can post (or send me) the updated code ? (with the bug fixes mentioned in the comments)
Thanks,
Daniel C.
[SDE, Sydney, AU]
djc@walla.com
|
|
|
|
|
|
|
Hi Dang.
Thanks for the codes.
BTW I found that the unzip didn't work properly if the zipped file has more than one layer of subdir, i.e. the files under two layers of subdire could not be unzipped correctly. EG. myfile.zip with
\*.*
\sub1\*.* // no problem
\sub1\sub2\*.* // having troubles
The unzip program of your other article "C++ wrapper for Gilles Vollant's Unzip API" works alright. But the check box of Ignore path information... not working. Checked or unchecked makes no difference.
Regards,
Ke
|
|
|
|
|
|
|
unzipping does not work.
The unzip program of your other article "C++ wrapper for Gilles Vollant's Unzip API" works alright. But it does unzip a empty subdire in *.zip.
|
|
|
|
|
|
|
Line 443 in Unzipper.cpp, *CHANGE* these:
if (!::CreateDirectory(szFolder, NULL))
return FALSE;
AS:
if (!::CreateDirectory(szFolder, NULL)) {
DWORD dwRet = GetLastError();
if(dwRet != ERROR_ALREADY_EXISTS)
return FALSE;
}
|
|
|
|
|
|
|
I'm trying to generate an OpenOffice .odt file (a Zip file containing xml files) automatically.
If I zip up the files using IZArc or other Zip programs, I can open them in OpenOffice OK. If I use this class, OO complains that the file is corrupt. However, if I open the Zip file, extract the files and re-zip them using another program then they work fine in OpenOffice.
Any idea what's different between the zip files produced by this code and the zip files that IZArc and other programs produce?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Rant 
Admin