ZIP?

[vefatica]

After I added the same file to the archive a second time, the archive more than doubled in size and contains exactly one file (which correctly UNZIPs to reproduce the original).

What are the extra million or so bytes doing?

v:\words\test> dir
2005-08-23  12:33  4,067,367  words

v:\words\test> zip words.zip words
<= V:\words\test\words

v:\words\test> zip /v words.zip
2005-08-23  12:33  4,067,367  73%  words

v:\words\test> dir
2005-08-23  12:33  4,067,367  words
2014-06-10  14:37  1,101,574  words.zip

v:\words\test> zip words.zip words
<= V:\words\test\words

v:\words\test> zip /v words.zip
2005-08-23  12:33  4,067,367  73%  words

v:\words\test> dir
2005-08-23  12:33  4,067,367  words
2014-06-10  14:38  2,203,075  words.zip

 

[rconn]

Your syntax is wrong (you should be using the /U option).

Regardless, I cannot reproduce the problem with 16.02.49.

 

[Charles Dye]

Regardless, I cannot reproduce the problem with 16.02.49.

Nor can we....

 

[vefatica]

Your syntax is wrong (you should be using the /U option).

Regardless, I cannot reproduce the problem with 16.02.49.

Regardless of my syntax, what TCC is doing is also wrong ... (apparently) leaving an inaccessible, possible outdated, space-consuming copy of the file in the archive. The default behavior for (Info)Zip and 7Zip is to add or update (can't speak for PKZip but I'd bet it's the same).

The internal GZIP does the same thing.

Is "I cannot reproduce the problem with 16.02.49" a new way of saying "Fixed in 16.02.49"? If so, I prefer the old way. I think users (certainly me) are more comfortable when you say "I fixed something" than when you say "I can't reproduce something" (in a build we don't even have).

Is it expected behavior that TCC delete the zip-file when the last/only file in it is deleted (ZIP /D)? That is not the behavior of (Info)Zip and 7Zip (again, can't speak for PKZip).

 

[Charles G]

You can get free demos of all / most of PkZip's programs at http://www.pkware.com/software - - -

 

[rconn]

Is "I cannot reproduce the problem with 16.02.49" a new way of saying "Fixed in 16.02.49"?

No, it means I didn't do anything to fix it, and I can't reproduce it with the latest builds, and there isn't any point in trying old builds. If you can reproduce it with the latest build (16.03.50, already uploaded) let me know.

 

[JohnQSmith]

I see the problem in the newest 16.03.51.

[Z:\temp]
08:49:24 $ ver

TCC  16.03.51   Windows XP [Version 5.1.2600]

0:00:00.001
[Z:\temp]
08:49:25 $ dir

Volume in drive Z is unlabeled      Serial number is 58b8:a853
Directory of  Z:\temp\*

2014-06-11  08:49         <DIR>    .
2014-06-11  08:49         <DIR>    ..
2014-06-04  15:52       5,239,373  sqlite3.c
         5,239,373 bytes in 1 file and 2 dirs    5,242,880 bytes allocated
    46,547,505,152 bytes free

0:00:00.003
[Z:\temp]
08:49:28 $ *zip sqlite.zip sqlite3.c
<= Z:\temp\sqlite3.c

0:00:01.262
[Z:\temp]
08:49:38 $ dir

Volume in drive Z is unlabeled      Serial number is 58b8:a853
Directory of  Z:\temp\*

2014-06-11  08:49         <DIR>    .
2014-06-11  08:49         <DIR>    ..
2014-06-11  08:49       1,457,783  sqlite.zip
2014-06-04  15:52       5,239,373  sqlite3.c
         6,697,156 bytes in 2 files and 2 dirs    6,701,056 bytes allocated
    46,546,046,976 bytes free

0:00:00.004
[Z:\temp]
08:49:39 $ *zip sqlite.zip sqlite3.c
<= Z:\temp\sqlite3.c

0:00:00.352
[Z:\temp]
08:49:46 $ dir

Volume in drive Z is unlabeled      Serial number is 58b8:a853
Directory of  Z:\temp\*

2014-06-11  08:49         <DIR>    .
2014-06-11  08:49         <DIR>    ..
2014-06-11  08:49       2,915,489  sqlite.zip
2014-06-04  15:52       5,239,373  sqlite3.c
         8,154,862 bytes in 2 files and 2 dirs    8,159,232 bytes allocated
    46,544,584,704 bytes free

0:00:00.004
[Z:\temp]
08:49:50 $ *zip /v sqlite.zip
2014-06-04  15:52      5,239,373   73%  sqlite3.c

0:00:00.047
[Z:\temp]
08:49:57 $

Edit: 32-bit XP SP3

 

[rconn]

I see the problem in the newest 16.03.51.

That's still invalid syntax, and I still can't reproduce it here.

I suppose I could add a check to ZIP to simply ignore an attempt to zip a file that's already in the archive.

 

[vefatica]

That's still invalid syntax, and I still can't reproduce it here.

I suppose I could add a check to ZIP to simply ignore an attempt to zip a file that's already in the archive.

Making the default "add or update" makes more sense.

 

[rconn]

Making the default "add or update" makes more sense.

How could choosing one of two contradictory things make more sense?

 

[vefatica]

How could choosing one of two contradictory things make more sense?

It makes a lot of sense to me ... if it's already there, update it, else add it. That's how InfoZip and 7Zip work.

 

[rconn]

But if it's already there, update means "don't do anything unless it's newer". So you're arguing for ignoring it?

 

[vefatica]

But if it's already there, update means "don't do anything unless it's newer". So you're arguing for ignoring it?

Yeah, if it's already there and the one being added isn't newer, ignore it.

I'm really only complaining about the extra, inaccessible stuff in the archive (repro'd by JohnQSmith). That's just dumb.

 

[JohnQSmith]

(repro'd by JohnQSmith)

Does it on my home computer (Win 8.1 64-bit) also.

[Z:\test]ver

TCC  16.03.51 x64   Windows 8.1 [Version 6.3.9600]

[Z:\test]*dir /hkm
1/27/2014  21:33       2,350,442  test.txt

[Z:\test]*zip test.zip test.txt
<= Z:\test\test.txt

[Z:\test]*dir /hkm
1/27/2014  21:33       2,350,442  test.txt
6/12/2014  22:14         254,130  test.zip

[Z:\test]*zip test.zip test.txt
<= Z:\test\test.txt

[Z:\test]*dir /hkm
1/27/2014  21:33       2,350,442  test.txt
6/12/2014  22:14         508,184  test.zip

[Z:\test]*zip /v test.zip
2014-01-27  21:33      2,350,442   90%  test.txt