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. -- 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 Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
