[Pan-users] Re: Pan error part_mid_buf_len' failed.

[Duncan]

Keith Richie <address@hidden>
posted address@hidden, excerpted below, on  Sat, 15 Mar 2008
09:49:04 +0000:

> I managed to "fix" it by deleting the tasks.nzb file from .pan2/. It
> happened to be 7.5mb large. Wondering if it was a corrupt post I had
> queued up? Or if there's a size limit to the tasks.nzb file? I did open
> the file in nano, but it became quite tiresome searching for anything
> erroneous in the huge amount of text. The first task, was just fine.

There shouldn't be a size limit to the file; if so it's the first I've 
read of it.  Corrupt post as you mentioned, possibly, or something I have 
seen, a post with a message-id that doesn't fit the spec.  I'd guess 
that's more likely, someone posting with a non-compliant news client, 
that spits out non-compliant message-ids, which of course are listed in 
tasks.nzb in newsbin format.  If it can't parse correctly because the 
message-id contained an illegal character...

If you kept a copy of the nzb around, and it didn't contain groups you're 
too uncomfortable sharing <g>, it might be worth filing a bug, and 
attaching that file.  If you wish (I absolutely understand if it 
contained groups you'd rather not...), you could even post it here (well, 
at 7.5 MB probably not), or better yet, put it up on your webspace or 
something (pastebin?) if you can, and then post a link to it.  Maybe 
someone will try verifying it.  That way, you'd have verification/
duplication of the bug on another system, so we know it's not just 
something with yours or a one-time thing, helping Charles a bit more.

Of course, not being a coder myself so the assert not meaning a whole lot 
to me, it could also be somewhere else, maybe a corrupted file/message in 
cache or the like.

One thing that's worth noting is that since pan builds the filename in 
cache based on message-id, if the message-id contains illegal characters 
(not entirely impossible, given someone posting in say China or Japan, 
with an entirely different character set, and possibly imperfect software 
converting that into ASCII compatible NNTP standard messages), it could 
cause pan to parse it one way when saving it to cache, then a different 
way when trying to retrieve it /from/ cache.  An assert means pan hit 
something it wasn't expecting, certainly, and if it had just downloaded 
the file to cache, passed a check saying it was there, then passed off 
the name to the save procedure and the save couldn't find the file the 
validation had just handed it as correct... well, that's exactly the type 
of thing that triggers an assert, and an illegal character in the message-
id is exactly the type of thing that triggers this type of scenario.  Or, 
due to the illegal character, the name handed off to the filesystem had a 
character that should have been escaped and wasn't, so then when pan went 
to actually use the file it just created, the filesystem said it wasn't 
there!  I know there's been at least one bug of this type before, as I 
remember it being discussed.  Just because the character isn't supposed 
to appear in the message-id (and therefore shouldn't need handled in the 
filename based off it), doesn't mean it /doesn't/ appear, and a well 
behaved app should be aware of and deal with that sort of possibility, 
but some times, something comes up that you literally could not and would 
not have ever predicted, as you literally didn't realize it was possible!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman