[Users] Timestamp consistency check

Erik Schnetter schnetter at cct.lsu.edu
Mon May 19 20:27:25 CDT 2008


On May 19, 2008, at 18:35:31, Ian Hinder wrote:

> Erik Schnetter wrote:
>> On May 19, 2008, at 15:28:55, Ian Hinder wrote:
>>
>>> Hi,
>>>
>>> I have recently had a problem with a fileserver which has its time  
>>> set
>>> incorrectly (6 minutes into the past).  The CST was looping
>>> indefinitely.  Would it be possible to add a little check into  
>>> Cactus
>>> somewhere which ensured that when a file is created, it gets a  
>>> timestamp
>>> which is not before the time it was created, and an error or warning
>>> printed if there is evidence that the fileserver time is incorrect?

Usually, make itself should at least complain (but maybe not abort).

>> Usually, make does not compare file timestamps to the current time,  
>> but
>> only compares file timestamps to other file timestamps.  This  
>> prevents
>> most of such problems since only the file server's internal  
>> consistency
>> is needed, not its absolute consistency with other machines.
>
> Ah - yes that makes sense. In my case, I think the problem might have
> been related to the ThornList file.  This was being copied from  
> another
> system, and its timestamp would have been preserved.

Normally, copying a file does not preserve the time stamp.  If the  
thorn list is copied or created anew, it should be tagged with the  
current time of the file server.  Did you copy the thorn list in a  
special way, e.g. explicitly preserving its time stamp?

>  So maybe the
> thornlist was being seen as newer than some other files in the
> configuration every time.  The test case that would catch this is to
> create a file, and determine what time the fileserver thinks it is,  
> and
> then to make sure that the thornlist is not newer than that.

Creating a file tags it with the file server's current time.  This is  
also the only way to query the file server about its idea of the  
current time.

>  But that
> catches a very specific case in a roundabout way, so maybe it is not  
> the
> right solution.  A generic test to verify the consistency of the
> fileserver's clock with the current system's current time would work  
> better.

That is possible.  One can create a file with the file server's  
current time and one with the local machine's current time, e.g. with

	: > server
	touch local

>> This fails if someone uses the command "touch", which (a) creates a  
>> file
>> and then (b) gives the file the current time of the machine where  
>> make
>> is running, not the file server's current time.  It is better to  
>> create
>> files with commands like
>>
>>    : > file
>>    echo > file
>
> Actually, the test case that I constructed was to touch a file and
> observe that the timestamp was in the past of a "date" command run
> before the touch.  So this suggests that the fileserver *is*  
> determining
> the timestamp, even with "touch".

That is very fishy.  It would also be easy to detect.

> Maybe the fileserver refuses to make
> a timestamp in the past, even if asked to by the client?

It shouldn't.  It doesn't on some LONI machines I just tested (touch - 
t 01010101 file).  Can you try the touch again and send a screen shot?

-erik

-- 
Erik Schnetter <schnetter at cct.lsu.edu>   http://www.cct.lsu.edu/~eschnett/

My email is as private as my paper mail.  I therefore support encrypting
and signing email messages.  Get my PGP key from www.keyserver.net.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
Url : http://www.cactuscode.org/pipermail/users/attachments/20080519/efae238c/attachment.bin 


More information about the Users mailing list