I have something that is similar or identical in binary newgroups. I am adding this comment in hope it adds something. This happened to me some time ago. If I try to save attachments I get a small .ERRORS file. I can see the picture just fine in the body pane. If I download the text I get a .msg file which size varies according to the content. If I download both text and attachments I get two .ERROR files plus a .msg file. If I download only the text, I only get a .msg file.
I then can use a program called UUD64Win from http:/www.marks-lab.com that I point at the .msg file and the picture extracts just fine. I had not made any changes in my PAN settings, or re-compiled or whatever. I suspect that M$ Windows 10 had some sort of update that spoiled things. The .ERROR files have a string such as: "ERROR: Write error on target file C:\Users\sarah\AppData\Local\Temp\uuH111I1: Bad file descriptor". There is lots of room on my C: drive. On Fri, Mar 25, 2022 at 3:55 AM Tom Tanner via Pan-users <pan-users@nongnu.org> wrote: > > On 24/03/2022 22:42, Duncan wrote: > > Tom Tanner via Pan-users posted on Thu, 24 Mar 2022 08:05:39 +0000 as > > excerpted: > > > >> On 24/03/2022 04:23, Duncan wrote: > >>> Dominique Dumont posted on Wed, 23 Mar 2022 11:51:20 +0100 as > >>> excerpted: > >>> > >>>> On Wednesday, 23 March 2022 11:21:54 CET Tom Tanner via Pan-users > >>>> wrote: > >>>>> I've been unable to save articles. The article is downloaded fine, > >>>>> but it produces a xxxxx.ERRORS file instead, > >>>>> with the contents > >>>>> > >>>>> ERROR: Write error on target file D:\Caches\TempDir\Temp\uuZNQJJ1: > >>>>> Bad file descriptor > >>>> That's a known issue on Windows: > >>>> https://gitlab.gnome.org/GNOME/pan/-/issues/106 > >>> The fact that the error persists > >>> no matter where you save the file, as well as the pointer to %TEMP%, > >>> indicates it's a problem there. > >>> > >>> How much free space on that partition? Just in case, you've tried a > >>> full reboot (not just a hibernate), right? What are the results of a > >>> fsck/ checkdisk/whatever run on that partition? > >>> > >>> And assuming you have the space, does starting pan with $TEMP pointed > >>> at a different partition (maybe a USB stick if you don't have a spare > >>> partition available) change the result? > >>> > >> There's no problem with space or the disc in general. I do full reboots > >> every day. As noted in a post that I guess crossed with yours, it's a > >> change introduced post 0.144. I had a look at the git diff and can't > >> see anything terrifically obvious so it might be a library issue. > > I saw that, but... if pan works for a bit and then develops an error that > > persists over both a pan restart and a full reboot, that means there's > > some state somewhere that's being retained over multiple sessions, which > > means it's being stored somewhere on disc. > > > > And if the error both persists no matter where the file is saved, and > > comes with an error message that points to somewhere in $TEMP, then > > there's a good chance the persistence of the error is related to > > something in $TEMP (but see the tasks.nzb discussion below as well). > > > > The other clue we have is the one you mentioned, that it's post-0.144, but > > could be in a (presumably bundled for MS Windows) library, not in pan > > itself. > > > > Those are pretty big clues to begin nailing down what and where the > > problem is, with the $TEMP information also a pretty good hint at a > > workaround in the mean time. > > > > So a few more questions about this error as I've a couple theories about > > what's going wrong. > > > > First theory, it's something in the temp dir as suggested above, with the > > bug likely in the bundled gmime library. > > > > Does the filename in the error change each time or does it remain the > > same, even after rebooting? Does the file named in the error actually > > exist, and if so, is it a binary or text file? > > > > Second theory, the temp dir stuff is a rabbit trail and the actual problem > > (at least where it persists, the trigger would be elsewhere) is in > > tasks.nzb, which could mean the bug is likely in pan code (which AFAIK > > does all the nzb handling, tho there's probably an XML parsing library > > that could also be bugged). Maybe a failed task is getting stuck in > > tasks.nzb and the bug is in the handling of whatever triggers the failure. > > > > Tasks.nzb should be located in pan's data dir. It is I believe a standard > > *.nzb file, plain-text in XML format, that contains the list of tasks pan > > still has to complete, or just a few standard formatting lines identifying > > it as an NZB file, without a task list if there weren't any pending tasks > > when it was last saved. > > > > With pan closed, try *moving* tasks.nzb elsewhere (don't delete it, save > > it for further investigation or to move back if the test doesn't get rid > > of the error) and starting pan again. Does that get rid of the error? > > > > If the error was in tasks.xml, open the file in a text editor and see if > > there's anything obviously wrong with it, and consider posting it if > > there's nothing pointing to possibly "sensitive" newsgroups or posts that > > you wouldn't wish to be public. > > > >> Unfortunately the instructions for building under windows are (a) scary > >> and (b) possibly out of date as they refer to gtk2 and I think pan is > >> using gtk3 now? > > Yeah. On Linux distros (particularly the more common/popular binary-based > > ones) the build instructions are bad enough, but it's still "ordinary- > > human possible", with some patience. On MSW, it's arguably out of the > > realm of "ordinary human" and into the realm of "better have some dev > > skills/experience", unless of course you are prepared to actually learn > > those skills as you go and can afford to spend possibly tens of hours over > > several days building and assembling the various pieces one by one, > > something relatively few have the time/patience/technical-mind luxury of > > being able to do. So I don't blame anyone stuck on MSW for a hesitancy to > > even /attempt/ a build of pan from sources -- I'd be quite reluctant > > myself. > > > I will have a further look, but when this started happening I renamed > the entire .pan2 directory so pan was starting up with no servers, > nothing, and it still happened (once I'd set up the configuration > obviously). It doesn't work for a bit. The functionality for saving > stuff does not work at all post .144. Apparently I upgraded pan at about > the same time as the big crash so thought it had magically stopped > working at the crash, and clearly that was unrelated. > > I can confirm the file named in the message does exist. It's just empty. > > > _______________________________________________ > Pan-users mailing list > Pan-users@nongnu.org > https://lists.nongnu.org/mailman/listinfo/pan-users _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
