Re: New scriptreplay is out-of-sync (longish)

[Karel Zak <kzak@xxxxxxxxxx>]

On Mon, Jul 28, 2008 at 05:40:00AM -0700, Micah Cowan wrote:
> - From a Correctness POV, the right way to deal with this is to fix
> script.c, not scriptreplay.c. The simple act of moving the newtime
> calculation to below the read, rather than before it (and, perhaps,
> calculating oldtime using gettimeofday, so we don't introduce a spurious
> ~half-second delay) will have things working better than they ever did,
> and result in a much more straightforward way to process the timing file
> (i.e., the way scriptreplay does it now).
> 
> - From a Pragmatism POV, though, there's the fact that, if we simply
> kludge scriptreplay.c to behave as the original did, then the timing
> files from all versions of script, new and old, will work with the
> current scriptreplay. If we fix script.c instead, then everyone has to
> be careful not to mix versions of script.

 The original purpose of the scriptreplay.c was to implement
 *backwardly compatible* replacement of scriptreplay.pl. From my point
 of view the out-of-sync problem is *regression* and should be fixed
 (also in 2.14.1).

 I think we have to support old (already generated) typescripts.

 I don't like the typescript "format". It's mess without a header and
 information about a version, ... so, I like the idea to implement a
 new better format (with timing?), but we have to support the old
 format too. I propose:

               1/ fix scriptreplay.c (just for backward compatibility)
  (optionally) 2/ create a new format

 Please, evolution, not revolution.

    Karel

-- 
 Karel Zak  <kzak@xxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html