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.