Re: [Gnu-arch-users] patch: automatic remove the corrupt revlib revision

[Andy Tai]

Tom, thanks for your comments and pointing out your opinions over similar 
additions in baz.  I
think what you said (and supported by several other people) is correct that tla 
sensibly does very
few "rm -fr" type (dangerous) operations and it is valuable to keep the 
evidences for debugging
and other purposes.  And indeed tla should rarely do such operations by itself.

However, it is also possible that the users want to delete such files.  Just to 
make it more
convenient if this is the desire, tla can automatically move such files to a 
directory called
,,to-be-deleted, with proper error messages.  Actual deletion must be done 
manually by the user. 
Is this more acceptable?

--- Thomas Lord <address@hidden> wrote:

> andy:
> 
>  > [....]
>  >> -              {
>  >> -                safe_printfmt (2, "corrupt library (failed inode
> signature validation)\n   
>  >> archive: %s\n    revision: %s\nYou should remove this revision from
> your library.\n",
>  >> -                               archive, revision);
>  >> -                exit (2);
>  >> +              { 
>  >> +                rmrf_file(rel_peek_str (revision_dirs, 0, 0));
>  >> +                continue;
>  >>                }
>  >>            }
> 
> 
> It's your call, Andy, but if you're soliciting opinions: I think that's
> a dumb idea.
> 
> One should always be extremely paranoid when injecting a call to
> `rmrf_file' into Arch.   It's just about the most dangerous function
> in the whole thing (and, indeed, is pretty darn dangerous).
> 
> Corrupt revision libraries should be a rare exception, not a rule.  If 
> in some situation they are not, the bug is that they are not rare in 
> that situation, not that the bogus revlibs are not automatically 
> removed.   Look elsewhere for a solution.
> 
> In some situations, a corrupt revision library is a serious clue to a 
> larger problem:  perhaps a disk has gone south in some unexpected way;
> perhaps an intrusion has taken place.  In these cases, the bogus revlib
> revision is a forensic clue and automagically removing it amounts to
> "collusion to destroy evidence".
> 
> I think you are are dangerously close to the trap that a certain subset
> of Canonical's awful hacking fell into:  
> 
> (1) some awkwardness is noted
> (2) a solution is proposed that eliminates the awkwardness in 80% of 
>     the cases
> (3) that gets implemented
> 
> (To really do the Canonical number you'd have to add "(4) Point at Tom's
> resistance of the 80% solution as reasons to beat him down still
> further")
> 
> The problem, as I see it, is *roughly* described this way -- this is 
> pseudo-quantization, not real quanitization:
> 
> The goodness of an 80% solution is:
> 
>    value-of-expected-consequence * .8
> 
> The badness is:
> 
>    cost-of-bad-case-consequences * .2
> 
> 
> The overall value of an 80% solution is:
> 
>    expected-case-value * .8 - bad-case-cost * .2
> 
> In this case, you're solving a problem that should never occur
> in the expected case.  Therefore, the solution you are thinking of 
> merging has, from my perspective, negative value.  It's just icing on 
> the cake that, when the problem occurs, the evidence you're proposing
> to destroy is valuable.
> 
> -t
> 
> 
> 
> 
>