Re: pan on windows

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

_______________________________________________
Pan-users mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/pan-users