Issue24

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

Created on 2009-11-30.14:46:09 by poeml, last changed by poeml.

Messages
msg75 (view) Author: poeml Date: 2009-12-01.20:58:37
No adverse effects observed with the fix. Seems to work. Closing this issue.
msg68 (view) Author: poeml Date: 2009-11-30.14:49:39
fixed in r7881
http://svn.mirrorbrain.org/viewvc/mirrorbrain?view=revision&revision=7881
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.
History
Date User Action Args
2009-12-01 20:58:37poemlsetstatus: testing -> resolved
messages: + msg75
2009-11-30 14:49:39poemlsetstatus: in-progress -> testing
messages: + msg68
2009-11-30 14:46:09poemlcreate