| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
|---|---|---|---|---|---|---|---|---|---|
| 0000937 | Spring engine | General | public | 2008-05-15 22:41 | 2008-05-21 16:29 | ||||
| Reporter | bibim_ | ||||||||
| Assigned To | tvo | ||||||||
| Priority | normal | Severity | major | Reproducibility | always | ||||
| Status | resolved | Resolution | fixed | ||||||
| Product Version | 0.76b1+svn | ||||||||
| Target Version | Fixed in Version | ||||||||
| Summary | 0000937: [SVN 5893] Checksum calculation problem | ||||||||
| Description | The 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 :/ | ||||||||
| Tags | No tags attached. | ||||||||
| Checked infolog.txt for Errors | |||||||||
| Attached Files |
| ||||||||
 Relationships |
||||||
|
||||||
 Relationships |
| Notes |
|
|
KDR_11k (reporter) 2008-05-16 14:05 |
-that explains why I never sync if I use the .bat file. |
|
imbaczek (reporter) 2008-05-16 22:16 |
the .bat file never manages to make the base files have the same size as the ones generated on Linux for me. |
|
bibim_ (reporter) 2008-05-17 00:41 |
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). |
|
tvo (reporter) 2008-05-20 20:52 |
changed to major |
|
el_matarife (reporter) 2008-05-21 02:55 |
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? |
|
tvo (reporter) 2008-05-21 15:44 |
We use CRC32 ... (7zip implementation) |
|
tvo (reporter) 2008-05-21 16:10 |
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) |
|
tvo (reporter) 2008-05-21 16:29 |
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 |