On 08/11/2009 08:54 AM, Karel Zak wrote:
See arbitrary regression test, it's almost always a check for a diff
between old and new output. We use it for filesystems detection (and
I will use it or PT parsing too). It might not be perfect, but...
Note that we still need to test the output from fdisk(s) for
regressions -- it's part of our API. Many people use the outputs in
their scripts.
Keeping outputs exactly "as is" can be a real challenge, especially if
you expect to keep things like whitespace, spacing, etc.
Also, I believe some kind of cleanup of the interface sometime
unspecified in the future, especially of the "fdisk" utility (not
[cs]fdisk) will be more or less necessary, and keeping backwards
compatibility would only make sense in understanding exactly the same
input sequences, not producing exactly the same output, especially in
the interactive parts. The current UI may be notoriously known by
everyone and unchanged for a decade, but still is rather crazy and
adding any more options may gradually become a hell.
Well, if you really want to use checksums and you know offset and
size of random bytes you can remove it from the image by sed (or so)
and then count the checksum.
It seems a bit hardcore to do in scripts, but it's definitely a way if
everything else fails. ;)
Also, I transcended from the blackbox approach and started looking for
the exact nondeterministic spots in other-than-dos label code which
broke my toys previously. Alas, it seems that sunlabel has mysteriously
become deterministic. But the message here is that the next time I bump
into such a thing, I'll see if adding an option which allows setting of
the conflicting parameter is easilly possible.
Zdenek
--
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