WZUNZIP -v "unsupported" [closed] - winzip

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
Here's a cmd.exe batchfile and its run results:
#ECHO OFF
SETLOCAL
SET "w=&echo."
FOR /f "delims=" %%i IN (%~f0) DO ECHO(%%i
ver%w%
ECHO(%PATH:;=&ECHO(%%w%
DIR *.zip%w%
DIR /s \wzunzip.exe \wzcline*.dll%w%
wzunzip -v ancient%w%
wzunzip -v ancient.zip%w%
GOTO :EOF
Run results:
Microsoft Windows [Version 6.1.7601]
C:\executable
C:\batch
C:\Windows
C:\Windows\SysWOW64
C:\Window s\system32
C:\Program Files\WinZip
C:\Program Files (x86)\Embarcadero\RAD Studio\9.0\bin64
C:\Program Files (x86)\Embarcadero\RAD Studio\9.0\bin
C:\FPC\2.6.2\bin\i386-win32
C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common
C:\Program Files (x86)\AMD APP\bin\x86_64
C:\Program Files (x86)\CollabNet
C:\Users\Public\Documents\RAD Studio\9.0\Bpl
C:\Users\Public\Documents\RAD Studio\9.0\Bpl\Win64
C:\Windows\System32\Wbem
c:\Program Files (x86)\Common Files\Acronis\SnapAPI\
c:\Program Files (x86)\Acronis\TrueImageHome\
C:\Program Files (x86)\ATI Technologies\ATI.ACE\Core-Static
C:\Program Files\TortoiseSVN\bin
C:\Program Files (x86)\RemObjects Software\Oxygene\bin
C:\Program Files (x86)\QuickTime\QTSystem\
C:\windows\System32\WindowsPowerShell\v1.0\
C:\opencobol\bin
C:\Program Files (x86)\OwlyCI
Volume in drive C has no label.
Volume Serial Number is 830B-46FA
Directory of c:\ttbackup\operational
20/04/2009 13:07 1,752,181 ancient.zip
1 File(s) 1,752,181 bytes
0 Dir(s) 129,259,110,400 bytes free
Volume in drive C has no label.
Volume Serial Number is 830B-46FA
Directory of c:\batch
15/07/2013 04:00 13,224 WZUNZIP.EXE
1 File(s) 13,224 bytes
Directory of c:\batchbackup
15/07/2013 04:00 13,224 WZUNZIP.EXE
1 File(s) 13,224 bytes
Directory of c:\Program Files\WinZip
15/07/2013 04:00 13,224 WZUNZIP.EXE
Directory of c:\Program Files\WinZip
15/07/2013 04:00 2,571,688 WZCLINE32.DLL
15/07/2013 04:00 3,084,200 WZCLINE64.DLL
3 File(s) 5,669,112 bytes
Directory of c:\Program Files (x86)\WinZip
15/07/2013 04:00 2,571,688 WZCLINE32.DLL
15/07/2013 04:00 3,084,200 WZCLINE64.DLL
2 File(s) 5,655,888 bytes
Directory of c:\Windows
15/07/2013 04:00 13,224 WZUNZIP.EXE
Directory of c:\Windows
15/07/2013 04:00 2,571,688 wzcline.dll
15/07/2013 04:00 2,571,688 WZCLINE32.DLL
15/07/2013 04:00 3,084,200 WZCLINE64.DLL
4 File(s) 8,240,800 bytes
Total Files Listed:
11 File(s) 19,592,248 bytes
0 Dir(s) 129,259,110,400 bytes free
WinZip(R) Command Line Support Add-On Version 4.0 32-bit (Build 10562)
Copyright (c) 1991-2013 WinZip International LLC - All Rights Reserved
ERROR: option v is unsupported
Program is terminating!
WinZip(R) Command Line Support Add-On Version 4.0 32-bit (Build 10562)
Copyright (c) 1991-2013 WinZip International LLC - All Rights Reserved
ERROR: option v is unsupported
Program is terminating!
Translating, this is Win7 Home Premium, Here's my PATH, directory of .zip files, directory of all occurrences of WZUNZIP.EXE and WZCL*.DLL.
I did have an older version WZCLINE.DLL so I overwrote it with the 32-bit newer version. The run results do not vary whether this WZCLINE.DLL file is present or not.
The results of two attempted listings is shown.
I'm sure this used to work on earlier versions. It is documented as working with the version I have (Winzip 17.5) but no combination of the -v switch appears to be processed according to the documentation.
I've tried -v and -V and -vb, -vr, -vi, -vm, -vt - all with precisely the same complaint from WZUNZIP.
Sadly, WINZIP has started to ignore me, after first having requested the following:
Please provide some additional information.
- Please describe the exact steps you take to cause this problem to occur.
- What version of Windows and of WinZip are you running (you can check the
· WinZip version by clicking WinZip's Help, About WinZip menu item)?
- Are there any error messages that appear? If so, please include the full
· text of the error message and the title of the error dialog box.
- Does the problem happen consistently, or does it appear to happen randomly?
- Does it happen with all files, some files, or one file in particular? If
· the problem happens with one file in particular, can you tell me how to
· obtain a copy of the file?
- Are there any other applications running when the problem occurs?
Please provide the screenshot of the error message you are getting. Please use the following link which will gives you more information in this issue: http://kb.winzip.com/kb/entry/21/
Most of that information is in the report I sent them, so I really don't have much hope of getting competent support there. The only information I can provide in addition is
Yes, it happens consistently on every .zip I've tried it on. - And the Point,click and giggle version has no problem decoding those files.
No, nothing else happening on the system at all.
7zip appears to list the contents happily.
So - anyone with a cure for this error with WZUNZIP? How do I get a file listing for a .zip file

After navigating through the endless canned responses, I finally got to communicate with a technician.
The problem was isolated to my haing changed the PATH sequence, and WZUNZIP was locating prior DLLs on the revised path, hence re-installing the CLI add-on was ineffective.
Uninstalled WINZIP, located all the stray WZ* elements and deleted them, reininstalled and sanity was restored.
(posted for the sake of those who may encounter a similar problem - as evidently some have, given there have been responses)

Related

lm command does not show correct module

I use WinDbg to analyze Adobe Acrobat Reader, AcroRd32.exe. I want to see what modules (the .dll modules that in the same directory with AcroRd32.exe) that AcroRd.exe loaded.
I use WinDbg monitoring to open a PDF file, then use lm command to show loaded modules. However, there is no module (.DLL) that has same directory as AcroRd32.exe.
Does that mean AcroRd32.exe didn't use these DLLs? To verify my assumption, I deleted all DLL files that are in the same directory as AcroRd32.exe. Then AcroRd32.exe cannot start normally. It means that these DLLs are necessary for AcroRd32.exe. But Why WinDbg's lm command didn't show these DLL modules?
Acrobat Reader starts another instance of itself. You need to debug the second instance to see the modules being loaded:
ntdll!LdrpDoDebuggerBreak+0x2b:
77e9db9b cc int 3
0:000> .childdbg 1
Processes created by the current process will be debugged
0:000> sxe cpr
0:000> g
[...]
Executable search path is:
ModLoad: 00c20000 00e45000 AcroRd32.exe
At this point, the second instance is going to be started.
1:010> g
ntdll!LdrpDoDebuggerBreak+0x2b:
77e9db9b cc int 3
1:010> g
If you break when Acrobat Reader has loaded, you'll see:
1:010> |0s
0:000> lmf
[...]
No Adobe Acrobat Reader DLLs
[...]
0:000> |1s
1:010> lmf
[...]
56910000 56961000 sqlite C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\sqlite.dll
56970000 569a4000 AXE8SharedExpat C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AXE8SharedExpat.dll
569b0000 56a9c000 ACE C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\ACE.dll
56aa0000 56d78000 CoolType C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\CoolType.dll
56d80000 56d9e000 BIB C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\BIB.dll
56da0000 572c2000 AGM C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AGM.dll
[...]
The first instance does not have DLLs loaded from Adobe Acrobat's directory but the second one has.

bash script calling rdiff-backup never ends

I want to run rdiff-backup and then switch of the raspberrypi it was running on.
I use the following script:
#!/bin/sh
date > /home/mik/rdiff-backup.log
echo "rsync start" >> /home/mik/rdiff-backup.log
rdiff-backup -v5 --print-statistics offlinebackup#server::/srv/backup /srv/datenserverBackup/backup >> /home/mik/rdiff-backup.log 2>&1
sync
date >> /home/mik/rdiff-backup.log
echo "rdiff-backup end" >> /home/mik/rdiff-backup.log
df -h >> /home/mik/rdiff-backup.log
sync
halt
The log file looks good (for the rdiff-backup part):
Sat 12 Aug 08:20:59 UTC 2017
rsync start
Unable to import win32security module. Windows ACLs
not supported by filesystem at /srv/backup
escape_dos_devices not required by filesystem at /srv/backup
Warning: name offlinebackup not found on system, dropping ACL entry.
Further ACL entries dropped with this name will not trigger further warnings
Using rdiff-backup version 1.2.8
Executing ssh -C offlinebackup#server rdiff-backup --server
-----------------------------------------------------------------
Detected abilities for source (read only) file system:
Access control lists On
Extended attributes On
Windows access control lists Off
Case sensitivity On
Escape DOS devices Off
Escape trailing spaces Off
Mac OS X style resource forks Off
Mac OS X Finder information Off
-----------------------------------------------------------------
Unable to import win32security module. Windows ACLs
not supported by filesystem at /srv/datenserverBackup/backup/rdiff-backup-data/rdiff-backup.tmp.0
escape_dos_devices not required by filesystem at /srv/datenserverBackup/backup/rdiff-backup-data/rdiff-backup.tmp.0
-----------------------------------------------------------------
Detected abilities for destination (read/write) file system:
Ownership changing On
Hard linking On
fsync() directories On
Directory inc permissions On
High-bit permissions On
Symlink permissions Off
Extended filenames On
Windows reserved filenames Off
Access control lists On
Extended attributes On
Windows access control lists Off
Case sensitivity On
Escape DOS devices Off
Escape trailing spaces Off
Mac OS X style resource forks Off
Mac OS X Finder information Off
-----------------------------------------------------------------
Backup: must_escape_dos_devices = 0
Starting increment operation /srv/backup to /srv/datenserverBackup/backup
Processing changed file .
Incrementing mirror file /srv/datenserverBackup/backup
Processing changed file abc
Incrementing mirror file /srv/datenserverBackup/backup/abc
Processing changed file abc/def
Incrementing mirror file /srv/datenserverBackup/backup/abc/def
Processing changed file abc/def/testfile.dxf
Incrementing mirror file /srv/datenserverBackup/backup/abc/def/testfile.dxf
--------------[ Session statistics ]--------------
StartTime 1502526061.00 (Sat Aug 12 08:21:01 2017)
EndTime 1502527913.72 (Sat Aug 12 08:51:53 2017)
ElapsedTime 1852.72 (30 minutes 52.72 seconds)
SourceFiles 151099
SourceFileSize 386321558216 (360 GB)
MirrorFiles 151097
MirrorFileSize 386321447731 (360 GB)
NewFiles 2
NewFileSize 110485 (108 KB)
DeletedFiles 0
DeletedFileSize 0 (0 bytes)
ChangedFiles 1
ChangedSourceSize 0 (0 bytes)
ChangedMirrorSize 0 (0 bytes)
IncrementFiles 4
IncrementFileSize 0 (0 bytes)
TotalDestinationSizeChange 110485 (108 KB)
Errors 0
--------------------------------------------------
The backup is working, but then the script ends right there.
rdiff-backup.log contains the full report of rdiff-backup. But neither the line "rdiff-backup end", nor the output of "df -h".
How can I make it ran to the end?
Thanks for your answers
I finally found a workaround, that solves my problem.
My sciprt which is called after booting from /etc/init.d is calling the other script which does the actual work (i.e. backup my data, and write the log file) as a background task.
/etc/init.d/CallAfterBoot.sh
#!/bin/sh
sleep 30
/home/me/DoBackup.sh & # '&' starts the script in background
/home/me/DoBackup.sh is the script I posted above which is now runing correctly.
Same script running as the same user now behaves differently. There's got to be some bug somewhere, however, it works for me now.

MDT 2012 image Failure - Unable to find Imagex.exe

I am running Windows Server 2012 R2 with MDT 2012, I installed the Windows 8 ADK before installing MDT 2012. I have created my Deployment Share and set everything up, but when I try to run the build it fails. I have included the error log bellow;
FindFile: The file imagex.exe could not be found in any standard locations. LTIApply 01/06/2015 09:54:30 0 (0x0000)
FAILURE ( 5441 ): 1: FindFile: imagex.exe LTIApply 01/06/2015 09:54:30 0 (0x0000)
Command completed, return code = -2147467259 LiteTouch 01/06/2015 09:54:30 0 (0x0000)
Litetouch deployment failed, Return Code = -2147467259 0x80004005 LiteTouch 01/06/2015 09:54:30 0 (0x0000)
For more information, consult the task sequencer log ...\SMSTS.LOG. LiteTouch 01/06/2015 09:54:30 0 (0x0000)
I see that it is unable to find the 'imagex.exe' file, where should this be located, and can I copy the file to the directory?
Any ideas?
Kind Regards,
Copy imagex.exe and wimgapi.dll (this may be optional, but I would still copy it) from the installation of ADK to the Tools\x86 and Tools\x64 directories in your deployment share.
For example (using 8.1 ADK instead of 8 ADK, folder names may be slightly different) the default installation on Server 2012 R2 would be "C:\Program Files (x86)\Windows Kit\8.1\Assessment and Deployment Kit\Deployment Tools\amd64\DISM" for the 64-bit imagex.exe and wimgapi.dll files. And "C:\Program Files (x86)\Windows Kit\8.1\Assessment and Deployment Kit\Deployment Tools\x86\DISM" for the 32-bit imagex.exe and wimgapi.dll files.
These files would be copied to the appropriate folders in C:\DeploymentShare\Tools\x64 and C:\DeploymentShare\Tools\x86.
This should resolve your problem. For whatever reason, MDT sometimes does not place all the needed files into the Tools folder when you create a deployment share.

Wierd behavior of db2ls when run from directory containing spaces

I am facing a strange issue with getting the db2 version using db2ls.
Below are 2 instances of db2ls execution
[root#dummy 6]# cd /tmp
[root#dummy tmp]# db2ls
Install Path Level Fix Pack Special Install Number Install Date Installer UID
---------------------------------------------------------------------------- -----------------------------------------
/opt/ibm/db2/V10.5 10.5.0.3 3 Tue Mar 10 01:38:53 2015 PDT 0
[root#dummy tmp]# mkdir test\ dir
[root#dummy tmp]# cd test\ dir/
[root#dummy test dir]# db2ls
/usr/local/bin/db2ls: line 43: cd: /tmp/test: No such file or directory
Install Path Level Fix Pack Special Install Number Install Date Installer UID
---------------------------------------------------------------------------------------------------------------------
/opt/ibm/db2/V10.5 10.5.0.3 3 Tue Mar 10 01:38:53 2015 PDT 0
It looks like db2ls is having issues when executed from a directory having spaces. Is this a known issue? I could not find any documentation for this. I am trying to circumvent this problem by using db2ls 2>/dev/null.
If there is a more efficient way please let me know.
http://www-01.ibm.com/support/knowledgecenter/SSEPGG_10.5.0/com.ibm.db2.luw.qb.server.doc/doc/t0023683.html
for DB2 installation paths it says
DB2 installation paths have the following rules:
Can include lowercase letters (a-z), uppercase letters (A-Z), and the underscore character ( _ )
Cannot exceed 128 characters
Cannot contain spaces
Cannot contain non-English characters
Reading statements like this are always a warning sign not to use spaces in paths in general. BTW, shell scripts don't play well with spaces in paths which is for me a good reason to avoid spaces in general.

OmniORB compilation error Windows 7 64 bit

Has anyone encountered the error below when compiling omniORB_4.1.6 64-bit for windows?
'RegQueryValueEx failed - error 109'
I followed the procedure in the readme.win32 and I get linking errors in the omniDyamic, codesets etc.. So someone suggested to rebuild the omniorb_root/src/tools/win32 and copy it in bin/x86_win32/. That's what I did and when I recompile the whole omniORB, the error is as below:
../../../../bin/x86_win32/omkdepend -D__cplusplus -D_MSC_VER -DIDLMODULE_VERSION
="0x2630" -DMSDOS -DOMNIIDL_EXECUTABLE -Ic:/python27/include -Ic:/python27/PC -I
c:/python27/include/python2.7 -DPYTHON_INCLUDE=<Python.h> -I. -I. -I../../../../
include -D__WIN32__ -D_WIN32_WINNT=0x0501 -D__x86__ -D__NT__ -D__OSVERSION__=4 -
D_CRT_SECURE_NO_DEPRECATE=1 idlc.cc idlpython.cc idlfixed.cc idlconfig.cc idldum
p.cc idlvalidate.cc idlast.cc idlexpr.cc idlscope.cc idlrepoId.cc idltype.cc idl
util.cc idlerr.cc lex.yy.cc y.tab.cc
RegQueryValueEx failed - error 109
-----------------------------------------------------------------------------------------------
make[4]: Entering directory `/cygdrive/c/Software/COTS/omniORB/omniORB_4.1.6/src
/tool/omniidl/cxx/cccp'
../../../../../bin/x86_win32/clwrapper -gnuwin32 -c -O2 -MD -GS -GR -Zi -nologo
-DHAVE_CONFIG_H -I. -I. -I. -I../../../../../include -D__WIN32__ -D_WIN32_WINNT=
0x0501 -D__x86__ -D__NT__ -D__OSVERSION__=4 -D_CRT_SECURE_NO_DEPRECATE=1 -Focexp
.o cexp.c
RegQueryValueEx failed - error 109
I'm going to answer my own question because it seems nobody has encountered this problem, and the mailing list is so quiet.
Someone suggested to me to recompile the src\tools\win32. So that's what I did and I copied the .exe files generated to bin\x86_win32.
I then compiled all the omniORB and get the RegQueryValueEx error.
The reason for this is when you check the src\tools\win32\bccwrapper.c in the void GetMounts(void) function,
it looks for this path in the registry:
Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\%02X.
When I checked that using regedit, I noticed that in the mounts->00, 01, 02, 03 etc.. keys, there are no 'unix' and 'native' string values inside those keys.
So I decided to delete all the keys and retained just the 00 and added a 'unix' and 'native' string value.
After which, I recompiled the src\tools\win32 and copied over the created .exe files to bin\x86_win32 and finally when I recompiled all the omniOrb, it started compiling (need to copy the ssl libs too) and finished successfully.
I really don't even know how the following got into my registry:
Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\%02X.
Best regards,
Mark
I spent quite some time trying to compile OmniORB on windows 10 with visual studio 2017.
Assuming Cygwin64 was installed in directory
c:\software\cygwin64
, the compilation of OmniORB is quite straightforward:
open a command terminal (cmd)
in that terminal, setup the Visual environment:
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat" x64
then, append the PATH (yes append and not prepend):
set PATH=%PATH%;c:\software\cygwin64\bin
then, in file config\config.mk, uncomment this line
platform = x86_win32_vs_15
in file platforms\x86_win32_vs_15, set PYTHON to target the python executable, in my case Python 3.6.5
PYTHON = /cygdrive/c/software/Python/python
finally start the compilation with make:
make export
Hope this helps.