RE: [stellation-res] Timing: The Problem

["Jonathan Gossage" <jgossage@xxxxxxxx>]

> >-----Original Message-----
> >From: stellation-res-admin@xxxxxxxxxxxxxxx
> >[mailto:stellation-res-admin@xxxxxxxxxxxxxxx]On Behalf Of Mark C.
> >Chu-Carroll
> >Sent: September 13, 2002 6:24 AM
> >To: stellation-res@xxxxxxxxxxxxxxx
> >Subject: Re: [stellation-res] Timing: The Problem
> >
> >
> >Is this really a problem outside of extremely canned situations like the
> >test scripts?
> >
> >Does anyone have a *real* scenario where they can modify a file, check
> >it in, then modify after checkin, and have the same timestamp?
> >
> >	-Mark
> >

Anyone who runs production scripts on a fast machine is potentially exposed
to the problem.
In the future, any program accessing Stellation through API's could also be
vulnerable depending on exactly what is being done. In general if you can
prove the existence of a hole like this, someone will find a way to drive a
truck through it.


> >
> >On Fri, 2002-09-13 at 14:04, Dave Shields wrote:
> >> Apologies in advance for the long note, but I think it raises a
> >> problem that must be addressed. If you are interested in working on
> >> the solution, please respond to the thread
> >>
> >>   Timing: The Solution
> >>
> >> which I will start shortly.
> >>
> >> Your timely responses to my request to "Could someone please run this
> >> program on Windows" showed we do indeed have a problem with time,
> >> namely Java's File.lastModified() method does not always work as one
> >> would expect
> >>
> >> The problem is not urgent, in that Eclipse does it right, as do the
> >> other reported systems, except for IBM's JDK 1.3 on Linux RedHat 7.1
> >> (the version I am using), and at least one version of Windows (Rodolfo
> >> Araya can provide the details).
> >>
> >> However, the problem is real. For example, Jonathan Gossage reported
> >> that his company has encountered several-second variations in clock
> >> time on various Unix systems. I originally ran into this problem when
> >> I noted failures on some regression tests, only to discover that two
> >> versions of a file that had changed were deemed to be the same since
> >> they were changed in the 'same' second.
> >>
> >> We could address this solely by an addition to the documentation.
> >> For example,
> >>
> >>   If you are using Version 1.3 of IBM's JVM on RedHat 7.1, then
> >>   after every checkin or checkout, please say the following phrase
> >>   to yourself
> >>
> >>       I wish IBM would fix the bug in File.lastModified
> >>
> >>   and make *sure* you take at least one second to do so.
> >>
> >> But -- eager programmers all -- we probably want to change the code.
> >>
> >> Now I could do it myself, but I think it best that I don't. Here's
> >> why.
> >>
> >> There is a more urgent problem -- this project will only succeed in
> >> the long run if we can get more non-IBM people involved -- and I see
> >> this file modification time problem as a good opportunity to do this,
> >> as we have a problem that is not urgent, provides a good introduction
> >> to the workspace code, and raises some interesting challenges.
> >>
> >> In brief, I'm going to leave it to the community to sort this out.
> >>
> >> I've just checked in a first cut in changes to the workspace
> >-- involving
> >> the classes Files, Checkin, Checkout, Configure, Files, Project, and
> >> Svc -- that do the following:
> >>
> >> 1) add a new option 'svc-check-wait' that can be used to wait for the
> >> clock to catch up after a checkin or checkout
> >>
> >> 2) add a new command 'svc configure client' that runs a variant of the
> >> Time program I posted yesterday to determine is the 'svc-check-wait'
> >> option is needed and installs an appropriate value in the current
> >> .svcrc file.
> >>
> >> 3) add a a test in the computeSignature() loop in Project so that, if
> >> 'svc-check-wait' has been specified with a value starting with '-',
> >> then file modification time will be ignored, and *all* artifacts will
> >> have their signature computed. This provides a starting point for
> >> investigating the performance issues. Is is really important to get
> >> the time right, or should we just compute all signatures all the time?
> >>
> >> I will post a followup note with the diff output showing my recent
> >> changes. If you read the code, you will learn how to add a new
> >> command, a new option, and how to affect execution of one of the most
> >> critical loops of the workspace (signature computation). I expect
> >> anyone working through this will find  bugs, or  ways to improve the
> >> system, or both. Doing it right may involve changing guide, tutorial,
> >> unit tests (which raises a problem in itself, as this problem only
> >> shows up on some operating systems), and so forth.
> >>
> >> Though in rough form, the code works in that, if I run the standard
> >> tests with the IBM 1.3 JVM on Linux, they fail, and now pass only
> >> if I first do
> >>       svc config system
> >> to set an appropriate wait value.
> >>
> >> The rest is up to you. I'm asking Florin and Ringo to coordinate any
> >> source commits. I'll try to stay out of this as much as possible,
> >> except to answer any queries about the workspace code.
> >>
> >> thanks,
> >> dave
> >>
> >> --
> >> Dave Shields, IBM Research, shields@xxxxxxxxxxxxxx.
> >> _______________________________________________
> >> stellation-res mailing list
> >> stellation-res@xxxxxxxxxxxxxxx
> >> http://dev.eclipse.org/mailman/listinfo/stellation-res
> >>

Regards

Jonathan

Personal Email
jgossage@xxxxxxxx

Business Email
jonathan@xxxxxxxxxxxxxx