Re: [Gnu-arch-users] PANIC: Top-of-file arch tag crosses 1k boundary

[Robert Anderson]

--- Original Message ---
From: address@hidden (James Blackwell)
To: address@hidden
Subject: Re: [Gnu-arch-users] PANIC: Top-of-file arch tag crosses
1k boundary

>> On Wed, 2004-08-25 at 14:01 +1000, Robert Collins wrote:
>>> On Tue, 2004-08-24 at 21:13 -0700, Tom Lord wrote:
>>> >     > From: "Robert Anderson" <address@hidden>
>>> >=20
>>> >     > Shouldn't the algorithm look for the tag at the
"bottom" location
>>> >     > _first_?  And only if no tag is found, to search the top?
>>> >=20
>>> > Unfortunate backwards compatability issue there.   No, it
needs to
>>> > search the top first.   The recently added error check is a
good thing
>>> > -- it should even be mirrored to check truncation of tags
at the
>>> > bottom.....=20
>>>=20
>>> IIRC There's not need to check that - it starts at the
beginning of the
>>> first line in the buffer, which means a truncated tag at the
bottom will
>>> not match at all. And as the bottom is the tail of the file,
it can't
>>> truncate content there...
>>>=20
>>> > but it appears to have been slightly botched in the
>>> > current instance.
>>>=20
>>> How so?
>>
>> I can think of one thing, which I overlooked initially -
Panicing, while
>> the right thing to do to prevent unexpected A+D pairs for
folk, breaks
>> the ability to check out code created while truncation was
allowed.
>>
>> I'm inclined to think that we want to resurrect truncation
while doing a
>> 'tla get'.
>
>We can get the same behavior by performing the following:
>
>1. today, change the panic into a stderr warning that support for 
>   this truncated id is going away

See my latest message "tag PANIC is a bug."  The id appears to
not be truncated, according the output of inventory --ids from
1.1pre9.

Bob