[Info-vax] fixing a saveset's attributes: attachment, not ftp
Stephen Hoffman
seaohveh at hoffmanlabs.invalid
Mon Jun 22 15:24:36 EDT 2015
On 2015-06-22 18:16:40 +0000, hb said:
> On 06/22/2015 07:05 PM, Stephen Hoffman wrote:
>> But the implementation of BACKUP here is... broken. Or we wouldn't
>> still be having this discussion. Again.
>
> You mean the "solution" /REPAIR is broken, or?
I mean that BACKUP is being unnecessarily intolerant about its input
file handling here. BACKUP should better follow the classic tenet "Be
strict in what you send and tolerant in what you receive." But then
I'm in a particularly charitable mood today, too. BACKUP should be
able to open and to read and verify the integrity a saveset its been
presented, and resolving any metadata confusion transparently. Even an
informational here is... well, why even bother the user, if the
checksums verified and the BACKUP worked?
I'd be slightly more forgiving around a tool that wasn't designed with
robust saveset file integrity checking, and expressly intended for data
recovery from potentially flaky input devices and potentially corrupt
files. To a tool that wasn't so often fodder for these "how do I fix
it?" discussions with inexperienced users. That's before considering
that some of the users will be working under pressure to get a server
recovered and operational, too. But then we've been fixing this
BACKUP metadata setting for how many decades, yet BACKUP can't manage
to open and read and verify the file itself, without needing the
associated metadata manually reset via BACKUP /REPAIR or via some DCL
or other hackery?
Or is this particular user interface error so familiar and so large
that few notice it anymore?
--
Pure Personal Opinion | HoffmanLabs LLC
More information about the Info-vax
mailing list