Keith Richie <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], 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 _______________________________________________ Pan-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/pan-users
