[Quilt-dev] Re: Link check after pop really needed? (was: Another shell re-write of backup-files)

[Jean Delvare]

On Monday 21 March 2011 01:40:37 pm Jean Delvare wrote:
> Honestly, I have no idea what case is supposed to be handled by the
> just-in-case link breaking (other than "user shot him/herself in the
> foot on purpose".) It looks totally paranoid to me, and I'd get rid
>  of it. But I can only imagine that I'm missing a case were it would
>  actually have saved someone's work. This decision if beyond the
>  scope of the C-to-bash conversion anyway.

I looked some more into this. This behavior is pretty old. The code as 
it exists today is from June 2004 and this commit from Andreas:
http://git.savannah.gnu.org/cgit/quilt.git/commit/?id=eb1a6de33c1b631e4636ff26dde2945a0db8db74

But the idea of checking for hard links after unapplying patches is even 
older, March 2004 and this commit still from Andreas:
http://git.savannah.gnu.org/cgit/quilt.git/commit/?id=a8592ac4467b34abd9b0ffae9192163dc68112bc

So I start wondering if this check is still needed today. It could as 
well be that the internal state representation made it required back 
then, and no longer. The comment in the code:

if [ -z "$patch" ]
then
        printf $"No patches applied\n"
else
        # Ensure that the files in the topmost patch have a link count
        # of one: This will automatically be the case in the usual
        # situations, but we don't want to risk file corruption in weird
        # corner cases such as files added to a patch but not modified.
        $QUILT_LIB/backup-files -L -s -B $QUILT_PC/$patch/ -
        printf $"Now at patch %s\n" "$(print_patch $patch)"
fi

doesn't really enlighten me. I tried to add a file to a patch without 
modifying it, but did not notice any problem, and as a matter of fact 
the unlinking code (which I made verbose for the purpose of this test) 
did not trigger.

So I am now under the impression that this check (and the implementation 
in backup-files) could be removed. Andreas, what's your opinion?

FWIW, the test suite doesn't currently trigger this condition. If it can 
really happen, it should be covered by the test suite.

Thanks,
-- 
Jean Delvare
Suse L3