Re: pan on windows

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
[email protected]
https://lists.nongnu.org/mailman/listinfo/pan-users