>> >> 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. _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
