> We do use the current time. The problem is that if it is a day in the > past we will see yesterday's DBR update, and if it is a day in the > future we probably won't see anything.
I don't see that as a problem if the client has an incorrect clock but it's a more serious problem if the client has the correct time but is accessing freenet via FCP over a lan (say) to where fred is running on a machine with an incorrect clock. However if the freenet client (or web browser) does not send its time with the FCP requests (or HTTP requests) then there is probably nothing anybody can do about this. It's not that much of a big deal, really, though. > THE DATA STORE. We store the LRU in the accessed times of the files in > the datastore (as well as in RAM). And it doesn't matter whether it is > "absolute time" as long as it is monotonically increasing. What really > stuffs us is if the clock is set back. Sorry, of course. If you're just making use of the OSs access time stamping then again there's nothing that can be done here other than using slower indexes. However it could be possible to store a timestamp that isn't the real time, but is monotonically increasing, based on the timestamp of the most recently used file plus some small fixed offset (I would suggest 10 seconds). d _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
