Questions re: Internal ZIP command

Dec 7, 2009
238
2
Left Coast, USA
TCC 15.01.52 x64 Windows 7 [Version 6.1.7601]

I've hardly ever used the internal zip feature much but after seeing a post about it here, decided to give it a longer look. I created two one-line text files (file1.txt and file2.txt), then:

zip /a test.zip file*.txt

Created TEST.ZIP. Then, just to see what the screen would show:

zip /f test.zip

No screen display. Then I tried it again:

zip /f test.zip

... and got this:

Usage : ZIP [A:[[-][+]rhsdaecjot] /A /C /D /En /F /I /Ln /M /P /O:[-]adegnrstu /
P /Q /R /S"password" /T /TEST /U /V /YC /Z"..."] ziparchive [@file] file...

The appearance of that error message is intermittent. Sometimes, after creating a brand-new ZIP archive, I run the "zip /f test.zip" command and the error message does not appear.

I ran zip without any arguments. This opened the internal ZIP in "GUI" mode — a window. In the window, I entered only the ZIP file's name and clicked the "Update existing files only" check-box. Same error message appeared.

So I take it the "freshen" command requires file specs in addition to the ZIP file's name. A short note about this in the online help would be worth adding.

But is this a bug?

zip /a test.zip .\

For the file spec, I used only ".\" — just a test to see what would happen. (Would TCC interpret the ".\" to mean "all files in the current directory"?)

The command actually deleted the existing ZIP file, and then the message appeared: "(SYS) The system cannot find the file specified."

Why would it be deleted? If it's a syntax error, so it goes . . . but deletion? That can't be right.
 

rconn

Administrator
Staff member
May 14, 2008
12,367
150
TCC 15.01.52 x64 Windows 7 [Version 6.1.7601]

I've hardly ever used the internal zip feature much but after seeing a post about it here, decided to give it a longer look. I created two one-line text files (file1.txt and file2.txt), then:

zip /a test.zip file*.txt

Created TEST.ZIP. Then, just to see what the screen would show:

zip /f test.zip

I don't know what you're trying to do here (other than deliberately failing the command?). The /F option requires filename arguments to update in the zip archive, and you're not supplying any. (Were you expecting an automagical update of random files?)

But is this a bug?
zip /a test.zip .\

For the file spec, I used only ".\" — just a test to see what would happen. (Would TCC interpret the ".\" to mean "all files in the current directory"?)

The command actually deleted the existing ZIP file, and then the message appeared: "(SYS) The system cannot find the file specified."

Why would it be deleted? If it's a syntax error, so it goes . . . but deletion? That can't be right.

WAD - that's the way the zip library works. I suppose you could argue it either way, but the way the library developers are thinking is that you wanted to modify the zip file; since that couldn't be done the file was deleted rather than being left in a (presumably) erroneous state.
 
Dec 7, 2009
238
2
Left Coast, USA
Indeed you could argue it either way. 7zip's "freshen" command is a string of weirdly complicated switches+arguments, but it's basically: 7z switches archive-name -- with no additional filename arguments required. As I recall, wzzip.exe's "freshen" command works the same way: if you want the entire archive's contents to be "considered," you don't specify particular "member" files to be freshened. I don't think it's an unconventional assumption to make about an archiver's command line. Permit me to suggest a short line in future documentation of the "/f" switch, reminding the reader that this operation requires "member" filename arguments.

So...why would the solution to putting the archive into a bad state be to delete the file? Who benefits from it? There is certainly an alternative: don't delete it; issue a warning and halt, returning a non-zero exit code.

I didn't set out to make the command fail, deliberately. (If I were still doing software testing, I surely would -- it'd be the first thing I'd do. In those days I could easily break about 3/4 of the internal-use-only software tools within the first few minutes of using them, via simple deliberate-failure commands. Of course nobody there wanted to fix the most obvious bugs...but that's a story for some other day.) That it fails with such a catastrophic result for the user isn't an appropriate response from the ZIP library. The people who developed the library should consider additional error-checking. Whether or not it was a mistake by the end-user, deleting a file in the absence of an explicit "I want this deleted" command of some sort is not a good thing -- the software equivalent of meting out the death penalty for a misspelling. :/
 
Dec 7, 2009
238
2
Left Coast, USA
IMHO your tests show GIGO...
Yeah, good point: what happens if the user makes an incorrect assumption about how the command line might work*...or, say, hits the ENTER key a bit earlier than he expected?** If it happens that his file is simply deleted despite his not having given an explicit "delete" command, then oh well -- it was garbage in, so why not garbage out?

The tough-love concept. Make a mistake, put garbage on the command line: file gone, get over it, you probably deserved it. Fabulous.

Rule #1: all user input is suspect. Plan accordingly. Neither accommodate or "enable" bad habits, nor punish your end-user for a simple error.

* What self-respecting software would ever think of '.' or '.\' as meaning 'everything in the current directory'? Only minor, barely-known tools such as 7zip...what would those guys know...honestly, what a silly idea. And what archiving software would consider "/f" or "-f" (or the equivalent) plus the archive file's name alone as a viable command line?

** Not that such things ever happen, of course.
 
May 20, 2008
3,515
4
Elkridge, MD, USA
Yes, hitting a key which prematurely executes a command (or posts a forum message) is the nature of the beast. Err safely is what the software ought to do, never deleting potentially irreplaceable information because of an incorrect command. If a command is ostensibly for updating an object (the archive in the posted event), and the update information is missing from the command (or the disk), retaining the old version is never fatal - it can be deleted later. Does the ZIP command delete an old archive file if there is a disk read error when attempting to add another file? If so, I suggest all users execute SETDOS /I-ZIP to stop using the command accidentally.
 
Similar threads
Thread starter Title Forum Replies Date
vefatica Questions about aliases. Support 1
vefatica Long file names - a few questions Support 2
C DIFFER questions.... Support 66
Mezlo menu batch file questions Support 25
S FORUM questions Support 2
C z_newmove.btm questions Support 6
S Documentation Questions re: ON Support 13
C TPIPE questions.... Support 5
S PDIR and @LABEL questions Support 4
S Questions about new build announcements Support 0
C tpipe questions Support 5
aedthuio Some questions Support 10
C @shfolder questions Support 7
gschizas Licensing questions Support 3
S Documentation File reading questions Support 4
M Just some questions about TCC "hanging" and PIDs... Support 4
ehab aboudaya How to? 2 GUI questions and return HWND using TakeCommandIPC Support 3
S Questions about @winapi/@capi Support 8
M Questions about @Assoc and @FType... Support 18
M A questions about @Files "+d" Support 35
mikea TCC v12 startup questions Support 15
S ON and REBOOT questions Support 3
S xxxMONITOR command questions Support 1
mikea BDEBUGGER/IDE questions Support 16
P Installer questions/gripes Support 2
C General questions Support 9
vefatica Vista questions Support 4
H IDE v10 questions Support 2
S V10 questions Support 8
C Few questions and suggestions Support 2
nikbackm IFTP questions Support 3
fpefpe How to? free (internal) command Support 0
Joe Caverly Documentation Replace internal command with LIBRARY command Support 0
T Returning a value from internal Lua scripts to TCC Support 2
rps For loop internal %_for_files variable? Support 2
Joe Caverly Why does TCCRT return VIEW as an internal command? Support 6
F How to? Disable TCC's internal response to Alt-F4 Support 8
vefatica @EVAL's internal precision? Support 9
jfalch WAD internal "which" should check for FILEEXIST when using AppPaths entry Support 8
P Can't disable internal tar, at least in pipes Support 3
M Keywords for commands, functions, internal variables Support 3
D WAD Internal variable _cpu is undefined Support 2
E View (internal command) does nothing now Support 3
D Minor problem. Incorrect value internal var _dir_files Support 7
jbanaszczyk Alias for internal command Support 8
Joe Caverly Internal Lua and require Support 0
R Fixed Internal ZIP command fails to process multiple files Support 3
D Internal variable _tctabs within TCExit Support 9
epement no internal help for 'v' in TCmd v14 Support 6
R Override TCC internal commands Support 2

Similar threads