MantisBT
Main | My View | View Issues | Change Log | Roadmap
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001671SUMoBugpublic2012-08-10 04:422012-08-17 21:02
Reporterbytehead 
Assigned ToKyle_Katarn 
PriorityhighSeveritymajorReproducibilityalways
StatusacknowledgedResolutionopen 
PlatformIntel x64OSWindows 7OS VersionUltimate x64 SP1
Product Version3.4 
Target VersionFixed in Version 
Summary0001671: Unreliable version comparison algorithm + File_Version / Product_Version mess
DescriptionAs seen on the screenshot most Dexpot's components have equal {Product;Company} data. In this case update info and markings by SUMo become totally illogical and messy:

a) dexpot64.exe (last row) from \backup_2075 shows v1.5.13 (which is true Product_Version), while another dexpot64.exe (prev. row) instance reported as v1.6.0.0 (which is File_Version in fact, real Product_Version is 1.6.0). Yet, SUMo shows OK mark for *both* entries.

b) dexpot.exe (32-bit) from \backup_2106 shows v1.6.0.0 (which again is File_Version exactly, actual Product_Version is 1.06) and says there's an update available of v1.6.1.0; another dexpot.exe instance (next row) reported as v1.06.0001.0 (which is true Product_Version here) and is marked as not needing update (OK). At the same time, dexpot.exe copies on other rows that have v1.05.099.0 (Product_Version) shown as having updates to v1.6.1.0.

So, by SUMo arithmetic: 1.05.099.0 < 1.6.1.0 < 1.06.0001.0 (sic!) And where the alleged latest v1.6.1.0 was derived from exactly? File_Version or Product_Version this time?

CONCLUSIONS:

1) as already reported in related bug 0001667, SUMo sometimes confuses File_Version and Product_Version data, and now it seems like a more common issue than JRE specific;

2) SUMo version comparison algorithm sometimes gives inconsistent/illogical results.
Additional InformationRULES TO FOLLOW, IMHO:

1) Product_Version must always take precedence (when present) over File_Version;

2) Before comparison, version strings must be preprocessed, and then compared as numbers (e.g. split strings into tokens using "." as a separator, get rid of leading zeros in every token, typecast tokens to integers and only then compare them in pairs left to right).
TagsNo tags attached.
Attached Filespng file icon inconsistent version comparison.png [^] (30,159 bytes) 2012-08-10 04:44


png file icon dexpot_backup2106.png [^] (31,268 bytes) 2012-08-10 04:44


png file icon dexpot_newer.png [^] (37,301 bytes) 2012-08-10 04:45


png file icon dexpot64_backup2075.png [^] (31,651 bytes) 2012-08-10 04:45


png file icon dexpot64_newer.png [^] (43,349 bytes) 2012-08-10 04:45


png file icon Aurora Firefox (harder case).png [^] (40,044 bytes) 2012-08-13 14:27


png file icon Aurora_16.0a2.png [^] (50,688 bytes) 2012-08-13 14:47

- Relationships
related to 0001667resolvedKyle_Katarn Inconsistent usage of File_Version / Product_Version fields for JRE components 
related to 0001694acknowledgedKyle_Katarn Duplicate filter (same product, same version, same company) should explore deeper 
related to 0001693resolvedKyle_Katarn \update\ in path to be used for filtering installers 

-  Notes
(0001108)
bytehead (updater)
2012-08-13 14:44

 I also wonder what should we do in cases like Aurora Firefox when there're non-numeric chars in version data (e.g. ProductVersion = 16.0a2; FileVersion = 16.0.0.4607).

Possible ways:
1) just truncate and ignore anything non-numeric (I guess that is the case now), e.g. 16.0a2 -> 16.0;
2) take any non-numeric chars (not only ".") as a separator and split into integer tokens, e.g. 16.0a2 -> {16;0;2}
3) use FileVersion instead when ProductVersion contains any non-numeric chars (apart from ".")
4) ???

Any better ideas?
(0001109)
bytehead (updater)
2012-08-13 15:09
edited on: 2012-08-17 21:02

 Kyle, here's one more thing I've been wondering about:

AFAICT, there's no such thing as a dedicated "Company" field in PE header, the closest match I can find is a "Copyright" field and sometimes "Legal trademarks". How does SUMo derives Company info exactly? Is it usually just a stripped down "Copyright" string (e.g. w/o (c), copyright, 19*, 20* and similar tokens)? Or is it derived from registry scan?

I also noticed quite a lot of files have hard-coded Company info exceptions (like Firefox, Java, Flash, etc.), what are they triggered by: path, filename, Product_Name? Is this hard-coded in the client itself or mapped on the server side?

- Issue History
Date Modified Username Field Change
2012-08-10 04:42 bytehead New Issue
2012-08-10 04:44 bytehead File Added: inconsistent version comparison.png
2012-08-10 04:44 bytehead File Added: dexpot_backup2106.png
2012-08-10 04:45 bytehead File Added: dexpot_newer.png
2012-08-10 04:45 bytehead File Added: dexpot64_backup2075.png
2012-08-10 04:45 bytehead File Added: dexpot64_newer.png
2012-08-10 04:46 bytehead Relationship added related to 0001667
2012-08-10 23:30 Kyle_Katarn Assigned To => Kyle_Katarn
2012-08-10 23:30 Kyle_Katarn Status new => acknowledged
2012-08-13 14:25 bytehead Summary Inconsistent version comparison and File_Version / Product_Version mess => Unreliable version comparison algorithm + File_Version / Product_Version mess
2012-08-13 14:25 bytehead Additional Information Updated View Revisions
2012-08-13 14:27 bytehead File Added: Aurora Firefox (harder case).png
2012-08-13 14:44 bytehead Note Added: 0001108
2012-08-13 14:47 bytehead File Added: Aurora_16.0a2.png
2012-08-13 15:09 bytehead Note Added: 0001109
2012-08-13 15:09 bytehead Note View State: 0001109: private
2012-08-13 15:22 bytehead Note Edited: 0001109 View Revisions
2012-08-14 00:11 Kyle_Katarn Relationship added related to 0001693
2012-08-14 00:15 Kyle_Katarn Relationship added related to 0001694
2012-08-17 21:02 bytehead Note Edited: 0001109 View Revisions
2012-08-17 21:02 bytehead Note View State: 0001109: public

MantisBT 1.2.15 [^]
Copyright © 2000 - 2013 MantisBT Team
Powered by Mantis Bugtracker