2025-07-02 23:39 CEST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000937Spring engineGeneralpublic2008-05-21 16:29
Reporterbibim_ 
Assigned Totvo 
PrioritynormalSeveritymajorReproducibilityalways
StatusresolvedResolutionfixed 
Product Version0.76b1+svn 
Target VersionFixed in Version 
Summary0000937: [SVN 5893] Checksum calculation problem
DescriptionThe checksum calculation algorithm in current SVN revision seems to be very sensitive to file order (or file date ?) inside archive files. For instance, I have two springcontent.sdz files which have exactly the same content, but have different checksums in the ArchiveCacheV6 file generated by Spring 0.76b1+ R5893. With Spring 0.76b1, these two bitmaps.sdz files have the same checksum.

This problem prevents people building their own Spring base files to be in sync with others, even if their archive files have the correct content :/
TagsNo tags attached.
Checked infolog.txt for Errors
Attached Files

-Relationships
related to 0000919resolvedtvo archive scanner sometimes returns -1 as an archive checksum 
+Relationships

-Notes

~0002285

KDR_11k (reporter)

-that explains why I never sync if I use the .bat file.

~0002286

imbaczek (reporter)

the .bat file never manages to make the base files have the same size as the ones generated on Linux for me.

~0002288

bibim_ (reporter)

Actually I never used the .bat file, both my archives are generated on the same Linux platform, but with different locales (which explains the different file listing order).
But the bug is more complex than I though. My archives have nothing to do with it. Here are my new experiments:

If I delete the ArchiveCache file each time I replace an archive, then the checksum is correctly generated when performing the archive scan (my two archives generate the same checksum).

If I replace an archive by a newer one and perform an archive scan without deleting the ArchiveCache file, then this new archive is given a bad checksum in the ArchiveCache file. This checkum doesn't match the old archive one nor the new archive one...

Then if restore the original archive and perform an archive scan (still without deleting the ArchiveCache file), this time the checksum doesn't change (the incorrect checksum stays in the ArchiveCache file).

~0002299

tvo (reporter)

changed to major

~0002303

el_matarife (reporter)

Is there some reason we're not using a fairly standard checksum available with implementation under the GPL? Can't we just grab some CRC32, MD5, etc implementation from some other program and use it in Spring?

~0002304

tvo (reporter)

We use CRC32 ... (7zip implementation)

~0002305

tvo (reporter)

I've a clue why it happens. Seems the 7zip CRC lookup table isn't initialized sometimes. (ie. when no 7-zip archives have been opened yet checksums are calculated incorrectly)

~0002306

tvo (reporter)

Fixed in r5918:
* Fixed mantis 0000937 and 0000919, "archive scanner sometimes returns -1 as an archive checksum".
  (I forgot to put the 7-zip InitCrcTable() in CRC.cpp after removing it from ArchiveScanner.cpp...)
+Notes

-Issue History
Date Modified Username Field Change
2008-05-15 22:41 bibim_ New Issue
2008-05-15 22:41 bibim_ File Added: springcontents.zip
2008-05-16 14:05 KDR_11k Note Added: 0002285
2008-05-16 22:16 imbaczek Note Added: 0002286
2008-05-17 00:41 bibim_ Note Added: 0002288
2008-05-17 23:10 imbaczek Relationship added related to 0000919
2008-05-20 20:52 tvo Note Added: 0002299
2008-05-20 20:52 tvo Severity minor => major
2008-05-21 02:55 el_matarife Note Added: 0002303
2008-05-21 15:44 tvo Note Added: 0002304
2008-05-21 16:09 tvo Status new => assigned
2008-05-21 16:09 tvo Assigned To => tvo
2008-05-21 16:10 tvo Note Added: 0002305
2008-05-21 16:29 tvo Status assigned => resolved
2008-05-21 16:29 tvo Resolution open => fixed
2008-05-21 16:29 tvo Note Added: 0002306
+Issue History