[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Pan-users] New Windows installer
From: |
Alan Taylor |
Subject: |
Re: [Pan-users] New Windows installer |
Date: |
Sun, 20 Mar 2016 14:49:41 -0300 |
>>
>> The fix/solution is to delete the existing C:/users/USERid/.pan2
>> directory before trying to install, because (I guess) the uninstaller
>> doesn't delete it and its presence somehow messes up the new install.
>> After deleting that directory Pan will install and run.
>
> It would be interesting to bisect it down to a specific file, and then,
> assuming it's a settings file, down to a specific setting in the file.
> But that's a lot of work some people won't have the time/motivation to
> do. But speaking from experience, knowing exactly what setting triggered
> the problem feels pretty good, as it helps put you in control of the
> problem, not the other way around. =:^)
I know what you mean and I'll give bisecting the .pan2 directory a try.
>
>> I think I had to reboot before my ISP would recognize Pan, otherwise I
>> got a "authentication required" error. Authentication is *not*
>> required on my fibre-to-the-home setup.
>
> One of the problems Linux users have been reporting is sort of the
> opposite of that, tho I don't believe the problem was an authentication
> error. Pan would work the first time after its directory was cleaned out
> and a new configuration created, but shutting it down and restarting with
> even the new configuration would result in problems, again. Pan would
> only work when started fresh, and couldn't work with an existing config,
> even if it had just rebuilt it, at all.
>
> So it's nice to see at least you aren't seeing that problem, even if a
> reboot is needed to get pan working properly.
>
> But that's one reason why bisecting the problem with the old config may
> be useful, because it may yield further hints on what's causing pan to
> dislike any config at all, on the Linux side.
I think rebooting is not a big deal myself. As I recall, I had been
running Grabit before installing the newest Pan so, even though Grabit
was paused there may have been something interfering with Pan.
Actually Grabit has its own problem - after running for some time it
starts to report "authentication required" (it isn't). The problem
may go away eventually, or I can restart Grabit and it works. No
cache problem I can find. In trying the bisect above I will find out
if installing Pan really needs a reboot in absence of any Grabit
activity. With Grabit I thought it might be my ISP because this
didn't happen some time ago..
>> Then pan runs fine, until the article-cache fills up. This is a problem
>> I have had with previous versions, I don't recall how many-seems like
>> all of them for the past 5(?) or more years.
>>
SNIP
>>
> How do you use pan to download those binaries? There are two
> possibilities, one of which should work fine with the default 10 MiB
> cache size, one of which will require a far larger cache size; I've
> worked with 12 GiB caches here. So see which of the following matches
> your download method and adjust either your method or your cache size,
> accordingly.
>
> In the one case, which to my knowledge works fine with even the tiny
> default 10 MiB cache, you select messages before downloading anything,
> and tell pan to download and save the attachments directly, using the
> "save" functions directly, before anything is cached. This works, or has
> in the past, anyway, because pan works on only a few messages at a time
> and knows what messages it has already saved the attachments from and can
> delete to keep the cache at its configured size.
This *is* how I use Pan, but 10 MB or 100 MB doesn't cover it. I am
now running 1000 MB article-cache and the size is staying at 799 MB
even while downloads continue successfully. So I may have worked
around my problem with the cache size although, as you say, it should
work at a much smaller cache.
>
> That's apparently how pan's long-time head dev, Charles Kerr, worked, and
> pan was designed around that download method, so it has worked pretty
> well. If that's how you're using pan and you're still having cache
> expiry problems, then you may well have found a new bug, or at least I've
> not seen it discussed here.
>
>
> The other alternative, which I tend to prefer, and which I'd guess most
> folks who started on USENET with MSOE (as I did, back in the MS Windows
> 95 era, with IE/OE4, before it was integrated into MS Windows 98) or
> similar tools may find more intuitive, is to first download messages of
> interest to cache (using cache article instead of save), then once
> they're in local cache, browse thru them, saving off attachments or
> deleting them as desired.
>
> Back in 2002 or so when I first started using pan, I couldn't figure out
> why it was deleting most parts of most messages before I'd even read
> them. It turned out that it was because I was using the second method,
> download to cache and then go thru the messages again when they're local,
> while pan's default cache size was designed with the first method in mind.
>
> If this is your problem as it was mine, there are two possible fixes.
> One is to change the way you work to fit the way pan was designed to
> work. Don't download to cache (the second method) any more. Instead,
> save attachments off directly (the first method), so they're saved as
> they download and pan's tiny 10 MiB default cache works fine.
I have tried this method and seen this problem myself with just-recent
versions of Pan, so now I use the method above and delete unwanted
downloads on my disk (saved using Read Article) rather from "Cache
Article".
Time to restart Pan is not a problem for me I guess because I have Pan
set to empty the cache at shutdown. Thus on start-up, the cache is
always empty.
Engineeral.