Reported updates includes a list of all root directories #9
Description
Example:
bin boot cache0 cache1 dev etc home lib lib64 lost+found media mnt opt proc root sbin selinux srv sys tmp usr var
I've not dug into the code yet to see where the problem lies.
Sampling of items in the SQLite database (/var/cache/email_updates/reported_updates.db):
sqlite> select * from reported_updates order by id desc limit 10;
607|bin boot cache0 cache1 dev etc home lib lib64 lost+found media misc mnt net opt proc root sbin selinux srv sys tmp usr var|2016-11-02 04:02:22 606|bin boot cache0 cache1 dev etc home lib lib64 lost+found media misc mnt net opt proc root sbin selinux srv sys tmp usr var|2016-11-01 04:02:28 605|bin boot cache0 cache1 dev etc home lib lib64 lost+found media misc mnt net opt proc root sbin selinux srv sys tmp usr var|2016-10-31 04:02:29 604|kernel.x86_64-2.6.18-416.el5|2016-10-29 04:02:25 603|bin boot cache0 cache1 dev etc home lib lib64 lost+found media misc mnt net opt proc root sbin selinux srv sys tmp usr var|2016-10-29 04:02:25 602|bin boot cache0 cache1 dev etc home lib lib64 lost+found media misc mnt net opt proc root sbin selinux srv sys tmp usr var|2016-10-28 04:02:26 601|bin boot cache0 cache1 dev etc home lib lib64 lost+found media misc mnt net opt proc root sbin selinux srv sys tmp usr var|2016-10-26 04:02:21 600|bin boot cache0 cache1 dev etc home lib lib64 lost+found media misc mnt net opt proc root sbin selinux srv sys tmp usr var|2016-10-25 04:02:11 599|tzdata-java.x86_64-2016h-1.el5|2016-10-22 04:02:22 598|tzdata.x86_64-2016h-1.el5|2016-10-22 04:02:22
Not only is the logic flawed that filters out applicable updates, but so is the logic that checks for previously reported updates. Entries 607 and 606 (ignoring all others) appear to be identical at first glance.