[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