Maybe I'm being too conservative. Can anyone imagine bad things that could happen if a 'segments' file's last modified date is set to something in the future? Typically this is compared with a previous value of its last modified date, not to the current time. I can't think of why one would ever compare this to the current time. So, unless someone can come up with a pitfall, I remove my objection to this solution.

Doug

Hani Suleiman wrote:
Well, the downside to doing that is that sleeping for 1 second really is
an awfully (unacceptably?) long time.

Doug Cutting said:

Hani Suleiman wrote:

Still doesn't 'feel' right though.

I agree. It makes it no longer a date field, but a version field. Any application which uses the value as a date may fail.

I think a better approach might be to define a sleep constant with
different values on different OSes.  It could be 1ms by default, and
1000 on OSX.  It would be better yet if the sleep time could be
determined based on the filesystem, and only set to 1000 for indexes
that reside on HFS systems, but that may or may not be easy.

Doug


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]






---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to