[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: John Meinel
Subject: Re: [Gnu-arch-users] PANIC: Top-of-file arch tag crosses 1k boundary
Date: Tue, 24 Aug 2004 22:05:33 -0500
User-agent: Mozilla Thunderbird 0.7 (Windows/20040616)

Hash: SHA1

Actually, I believe the algorithm is look at the bottom 1k, then look at
the top 1k. At least when I was doing some profiling of what system
calls were being performed, that's what I saw. That was my understanding
as to why all of Tom's files end in the arch tag, instead of start with it.

If you look at src/libarch/inv-ids.c on line 1335 you find "search the
file itself (last, then first 1k").
If you look through the code, it seems to seek to the bottom
(SEEK_END-1026), and then read in 1025 characters.

And it seems to return from the function if it finds a valid tag, so it
shouldn't be looking at both the bottom and the top.

I'm really curious what is happening? I also am grep'ing for the strings
"Top-of-file", and I can't find anything

Do I have a different 1.2.1 than you do? I got mine from And it has a valid signature from jblack.

Robert Anderson wrote:
| --- Original Message ---
| From: Aaron Bentley <address@hidden>
| To: Robert Anderson <address@hidden>
| CC: address@hidden
| Subject: Re: [Gnu-arch-users] PANIC: Top-of-file arch tag crosses
| 1k boundary
|>Robert Anderson wrote:
|>>This is the error messages I get when I do 'tla changes' using
|>>the 1.2.1, which I just installed:
|>>PANIC: Top-of-file arch tag crosses 1k boundary
|>>Any ideas?  I don't have any arch-tags at the top of files.  I do
|>>have some in very small files, however, that I suppose could be
|>>interpreted as the "top" even though they are closer to the
|>>bottom than the top.
|>Try to avoid one bug, you get another.  The rationale was that
| ids were
|>being truncated when their tags crossed the 1K boundary.  Rather
| than
|>fix it hastily, a PANIC was added, to prevent tla from silently
| doing
|>the wrong thing.
| Let me see if I understand.  There are two allowable places for
| tags in the file:  1k starting from the beginning of the file,
| and the last 1k of the file.
| The algorithm for finding a tag is: search the top, and if none
| is found, then search the bottom for the tag identifier.  If
| found in the "top", do this barrier-cross check on the tag to
| prevent unintended truncation.
| The failure mode here is that the tag was intended to be at the
| bottom of the file, but the file is short enough that the tag is
| in _both_ the "bottom" and "top" regions, although only partially
| contained in the "top" region.
| Shouldn't the algorithm look for the tag at the "bottom" location
| _first_?  And only if no tag is found, to search the top?
| Bob
Version: GnuPG v1.2.4 (Cygwin)
Comment: Using GnuPG with Thunderbird -


reply via email to

[Prev in Thread] Current Thread [Next in Thread]