Questions re: Internal ZIP command

[mikea]

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.

 

[Steve Fabian]

IMHO your tests show GIGO...

 

[rconn]

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.

 

[mikea]

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. :/

 

[mikea]

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.

 

[Steve Fabian]

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.