Thomas Thanks I will pass this on to our IT admin and hopefully he will look into turning on the long file name support.

We have a netware 3 server and for some reason pmail 4.5x will not run. We had to revert back to 4.41 to get it to work. Is there something we need to change on our server to get 4.5 to run properly? I had been running 4.51 for about a year in standalone mode on a WinXP system. They need to add me to the server so I could get internal emails. Any help is appreciated.

Not much I can help you with here except to say I've been using PMail v4.5 with a Netware v3.12 system since it was an alpha version. All I did was install v4.5 over v4.4 as an update.  I am using WinXP SP3.

Thomas - Thanks. I guess there is just something about how they have our netware 3 setup.

Check if you have the file w32nw3.dll in your Pegasus Mail program directory. If the file is missing you need to re-install Pegasus Mail with Netware support.

 
HTH,

Sven

Sven, w32nw3.dll was in the pegasus mail program. I just tried to use 4.52 again . I tried to install 4.52 as an update and as a new install but after the splash screen and mailbox lock screen ( I click continue) pegasus crashes. I installed 4.41 and it runs with out any problems.

Thanks

[quote user="rgtech"]Sven, w32nw3.dll was in the pegasus mail program. I just tried to use 4.52 again . I tried to install 4.52 as an update and as a new install but after the splash screen and mailbox lock screen ( I click continue) pegasus crashes. I installed 4.41 and it runs with out any problems.[/quote]

You may want to check the First Aid thread for possible crash conditions (aside from removing new mail messages from the respective directory for figuring out whether any of these cause the crashes).

Michael Thanks. It looks like it is related to spamhalter. I have XP running on a Pent 4 and did not have any new messages. With 4.4 installed I found the words4.db3 file and noticed that it was zero bytes. I exited pegasus then deleted the words4.db3 file. Tested Pegasus 4.4 and it started crashing. I turned off spamhalter and again tried to delete the words4.db3 file and pegasus 4.4 still crashing. I turned off spamhalter, deleted the file. I then found the old word4.db3 file from my old install which is about 6Mb in size and copied that to the mail directory. I was able to run 4.4 it without crashing. I installed 4.52 as update (not new install) and it ran without crashing. I then turned spamhalter back on without crashing pegasus 4.52.

I will run this for a few days to see what happens with the crashes - hopefully this is fixed on my system.

Any idea why I was getting words.db3 at zero bytes or is there a way around this if you don't have a trained file? If possible I would like to let our admin know so if he needs to install 4.52 we can do it even if he does not have a trained file since most people here have never turned on the spamhalter.

[quote user="rgtech"]Any idea why I was getting words.db3 at zero bytes or is there a way around this if you don't have a trained file? If possible I would like to let our admin know so if he needs to install 4.52 we can do it even if he does not have a trained file since most people here have never turned on the spamhalter.[/quote]

I have no idea how Spamhalter actually works, but when I tried running Pegasus Mail without any words.db3 file at all it simply created a new one without crashing.

Michael thanks for the help.

Just to check if it would help with this problem I installed the spamhalter update that fixed the new message zero byte problem and renamed the word4.db3 file but again this create a new zero byte words4.db3 and pmail crashed on exiting. I used the minidump program to send the crash info incase that may help find the root cause. Until then I will just make I always keep a good copy of my words4.db3 file.

[quote user="rgtech"]Just to check if it would help with this problem I installed the spamhalter update that fixed the new message zero byte problem and renamed the word4.db3 file but again this create a new zero byte words4.db3 and pmail crashed on exiting.[/quote]

It shouldn't create a zero byte DB3 file, on my system it creates a 4KB file, so there's some kind of file access issue involved, IOW: Something prevents Spamhalter resp. the sqlite3 module (I assume) from writing data to the DB3 file. So the question is: Who locks this file, a typical suspect for such behaviour would be an AV or other malware scanner.

If you train Spamhalter (just for testing), does the size of words4.db3 increase? Maybe using Sysinternal's FileMon can reveal more insights?

Michael - I used procmon (filemon no longer available). From what I can tell there was no access denied and the only program I noticed working on the file was win-pm32.exe. I did notice that after inital creation or access spamhalter tries to create a file called words4.db3-journal . Our netware 3 system is restricted to files names using the 8.3 (DOS) format. I put my trained words4.db3 file in and noticed prior to closing there are several reads to words4.db3 file which is were the crash seems to happen when trying to read a zero byte file.

If spamhalter is using the "-journal" file to update the words4.db3 file even my trained file may not be getting updated. Unless you have something else for me to look or if you wanted to check my procmon log file I guess I need to look into what spamhalter is trying to do with the "-journal" file or what happens when it can't create it. Do you know where I should look for information on spamhalter?

Thanks for all your help

[quote user="rgtech"]Our netware 3 system is restricted to files names using the 8.3 (DOS) format.[/quote]

Doesn't sound like I good idea in this context ...

[quote user="rgtech"]Do you know where I should look for information on spamhalter?[/quote]

No, I'm trying to get Lukas Gebauer to take a look at this thread, but I can't guarantee he's going to do so ...

[quote user="idw"][quote user="rgtech"]Our netware 3 system is restricted to files names using the 8.3 (DOS) format.[/quote]

Doesn't sound like I good idea in this context ... [/quote]

Just to add some more reasons: IMAP caching uses longer filenames, my HTML renderer replacement does as well ...

I have been trying for several years to get the file name restriction fixed but they keep telling me it's not an easy fix. Does anyone one know the last version of pegasus that does not use any long file names?

This could explain a lot of the mysterious problems we have had in the past if some of the pegasus mail programs are trying to use long file names.

[quote user="idw"][quote user="rgtech"]Do you know where I should look for information on spamhalter?[/quote]

No, I'm trying to get Lukas Gebauer to take a look at this thread, but I can't guarantee he's going to do so ...[/quote]

His reply was: You need to enable long filename support and he doesn't recommend using Spamhalter on network installations for performance reasons and possible problems with file locking. You can disable Spamhalter by removing the library wi_sph.dll from Pegasus Mail's executable directory (the one containing WINPM-32.EXE).

According to Pegasus Mail's "What's new" section IMAP caching (using long hashed filenames) was implemented in version 4.2.

> This could explain a lot of the mysterious problems we have had in the

past if some of the pegasus mail programs are trying to use long file

names.

v2.54 or even earlier.  When PMail started using  the LDAP extension it started using long filenames.

> I have been trying for several years to get the file name restriction fixed but they keep telling me it's not an easy fix.

Not sure what they mean about n not being an easy fix though, takes just a few minutes to do the commands load os2 and add name space os2 to volume <volume name>

Thanks for all your help. Since I had ran in stand alone mode for several years I was never aware of the long filename requirements. I will be passing this on to our IT admin so he can decide how he wants to handle this.