metalink-hasher: doesn't set correct mtime in some cases

[poeml]

                                                                                            [          ]

Issue migrated (2015-06-05) from old issue tracker http://mirrorbrain.org/issues/issue24

Title    metalink-hasher: doesn't set correct mtime in some cases
 Priority   bug                  Status          resolved
Superseder                      Nosy List        poeml
Assigned To poeml               Keywords

msg67 (view) Author: poeml Date: 2009-11-30.14:46:08

Checking whether a saved metalink hash file is up to date, the comparison for mtimes doesn't
work sometimes. I encountered this case:

withlock ~/LOCK-ue-hasher metalink-hasher update -t /srv/metalink-

hashes/ue/srv/mirrors/ue /srv/mirrors/ue -v
looking at /srv/mirrors/ue
locked /srv/metalink-hashes/ue/srv/mirrors/ue/LOCK
Hashing '/srv/mirrors/ue/bar' ... <-----------
Up to date: '/srv/metalink-hashes/ue/srv/mirrors/ue/ultimate-edition-2.4-
x64.iso.size_2562793472'
Up to date: '/srv/metalink-hashes/ue/srv/mirrors/ue/ultimate-edition-2.4-
x86.iso.size_2534909952'
unlocking /srv/metalink-hashes/ue/srv/mirrors/ue/LOCK

The log shows how /srv/mirrors/ue/bar is re-hashed. However, the script always claims that.

Inserting a debug print shows that the mtime on the source and destination file are
slightly different (in subsecond range):

withlock ~/LOCK-ue-hasher metalink-hasher update -t /srv/metalink-

hashes/ue/srv/mirrors/ue /srv/mirrors/ue -v
looking at /srv/mirrors/ue
locked /srv/metalink-hashes/ue/srv/mirrors/ue/LOCK
src mtime 1259537492.4343064 <---------
dst mtime 1259537492.4343059 <---------
Hashing '/srv/mirrors/ue/bar' ...
src mtime 1257621747.0
dst mtime 1257621747.0
Up to date: '/srv/metalink-hashes/ue/srv/mirrors/ue/ultimate-edition-2.4-
x64.iso.size_2562793472'
src mtime 1257621923.0
dst mtime 1257621923.0
Up to date: '/srv/metalink-hashes/ue/srv/mirrors/ue/ultimate-edition-2.4-
x86.iso.size_2534909952'
unlocking /srv/metalink-hashes/ue/srv/mirrors/ue/LOCK

This means that os.utime() doesn't set the correct utime for some reason.

I'm fixing this in trunk by comparing int(mtime) to int(mtime) instead of a direct
comparison.

msg68 (view) Author: poeml Date: 2009-11-30.14:49:39

fixed in r7881
http://svn.mirrorbrain.org/viewvc/mirrorbrain?view=revision&revision=7881

msg75 (view) Author: poeml Date: 2009-12-01.20:58:37

No adverse effects observed with the fix. Seems to work. Closing this issue.

History
         Date         User  Action              Args
2009-12-01 20:58:37 poeml set    status: testing -> resolved
                                   messages: + msg75
2009-11-30 14:49:39 poeml set    status: in-progress -> testing
                                   messages: + msg68
2009-11-30 14:46:09 poeml create

(end of migrated issue)