/base/archives.bat -> Queries

[odie]

Hi developers,

I was twiddling with the file /base/archives.bat and came across an interesting thing today.

Previously, i proposed a change to the 7za command from -a to -u, the updating works.

Today, i notice something interesting.

When i had old files in place, i ran the batch file and the pk3 files were updated.

Then i moved these files somewhere, (so there be no more pk3 files) and ran the same batch file again. The re-created files were all ok, except for 1 file which had a difference in size.

The file is /base/0pics.pk3 has a different size (checksum too)
a) A clean built will result in a file size of 163 MB (171,323,324 bytes)
b) An update will result in a file size of 163 MB (171,336,978 bytes)

They are both on the same harddisk and partition, and on WinXp system. Was wondering if someone could explain or give me insight on this strange phenomenon?

The other 8 pk3 files compiled all has no such problems. Same file size, checksums.

PS: This is the command from the script that compiles 0pic.pk3, which i see no problem:

Code: [Select]

7za u -r -tzip 0pics.pk3 pics\*.jpg pics\*.tga pics\*.png textures\*.jpg textures\*.tga textures\*.png -x!".svn"


[Muton]

dont update pk3 files
delete them before and use option -a

[bayo]

Many things can explain that.

But it dont mean archive contents are not the same, but the compression (one file before another, the incremental compression itself... or anything else)

[odie]

dont update pk3 files
delete them before and use option -a

Muton, dun worry abt -a or -u option. I have tested it and it works and updates correctly. In fact i was the one who submitted the patch for the batch file "archives.bat" to be changed to -u.

This is a more efficient way to do pk3 files packing, as it only updates the changed files.

The question here i ask was why it was different for ONE of the file, 0pic.pk3 - difference in sizes, even though contents are identical.

Many things can explain that.

But it dont mean archive contents are not the same, but the compression (one file before another, the incremental compression itself... or anything else)

Actually, i was thinking more of along the line of incremental compression, cos pics usually has this wierd trait. But usually, the compression should ends up in the same checksum / size...... just curious why was mine different.....

Nvm tat. It works so it works. I am just being paranoid and meticulously scrupulous here. lol

[Muton]

 
Dont update pk3 files
If the dev's remove part of the code
as they did before
you'll end up with a crashing or whatever game
Its hard enough to trace down bugs.

I know what im talking
'couse my diff builds updating pk3 files on the user system

And for the diff hash and size of pk3
as in another topic
if multicore filesize can vary

[odie]

Dont update pk3 files
If the dev's remove part of the code
as they did before
you'll end up with a crashing or whatever game
Its hard enough to trace down bugs.

I know what im talking
'couse my diff builds updating pk3 files on the user system

And for the diff hash and size of pk3
as in another topic
if multicore filesize can vary

Actually, i am always curious abt 7za's full capability for the latest version.

I wonder if there is a removal of a certain files from the original archive, does the archiver detects? (Hmmm, let me do some experiements with tat).

Btw, i usually delete all my pk3 files before doing the compile_maps.