Re: [Pan-users] pan on windows

[Duncan]

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