This issue has indeed been solved in v4.6!

I had a test setup that invariably replicated the problem in v4.5. This morning I upgraded this test environment to 4.62, just to make sure, and the problem has vanished.

Bart

A problem I hoped v4.5 had solved occurred this weekend again: Mercury truncates all mail to 0 bytes.
Messages are delivered to the client like this:

  Received: from spooler by facodc.xx (Mercury/32 v4.52); 8 Sep 2007 17:21:55 +0200
  X-Envelope-To: bart@facodc.xx

That's all. The Mercury core window shows "Alias file sharing problem" many (hundreds of?) times.
The core and MercuryS logs don't show anything unusual, see excerpts below. Restarting Mercury solves the problem.

This issue was discussed before on the Mercury mailing list, then it was thought it would be solved by version 4.5.
I don't think there can be a real sharing problem: nor the Mercury machine nor the Novell server has an on-access virus scanner, and there was no backup job running at the time of the start of the incident. It may be significant that all three times this problem occurred it started around 17:00. BTW, the problem was worse with v4.01: I had to restore a backup of Mercury then because mercury.ini and several mailinglist files had also been truncated to 0 bytes.
 
Any ideas for a solution? The issue is quite serious as you will understand: 24 hours of mail were lost.
Could David Harris be persuaded to let Mercury shut down itself when this "alias file sharing problem" happens? Then at least nothing would get lost.
 
TIA for any ideas,
Bart

---------

Our setup:

Mercury 4.52 running on a Compaq P4 2.4 GHz
Windows XP Pro SP2
All files on a Novell volume except the primary queue and the scratch directory

MercuryS log for the message shown above:

T 20070908 172142 46dd31c4 Connection from 194.109.127.152
T 20070908 172142 46dd31c4 EHLO bsmtp3.xs4all.nl
T 20070908 172142 46dd31c4 MAIL FROM:<akstceblcommnsdgs@eblcom.ch> SIZE=5672
T 20070908 172142 46dd31c4 RCPT TO:bart@facodc.xx
T 20070908 172142 46dd31c4 DATA - 128 lines, 5727 bytes.
T 20070908 172142 46dd31c4 QUIT
T 20070908 172142 46dd31c4 Connection closed with 194.109.127.152, 0 sec. elapsed.
T 20070908 172316 46dd31c5 Connection from 194.109.127.151

Mercury core log for the message shown above:

I 20070908 1721 MG00736B akstceblcommnsdgs@eblcom.ch    bart.Dmn.FACO 5909

I have to say that I'm a bit stunned to see anyone reporting this problem with v4.5x. I put a very large amount of time into dealing with the problem, and I haven't seen a report of it from my test team for many, many months now.

In short, what this error message actually means is one of two things:

1: That there is a problem opening the alias file.

2: That Mercury has run out of file handles.

In most cases in the past, the cause was #2. Mercury can potentially run out of file handles if some condition arises that results in a file being opened but erroneously never closed (this is kind of like the file equivalent of a "memory leak"). Having said that, there should be no remaining condition in v4.5 where this is possible. The other possibility is simply that Mercury has more files open at one time than the compiler's runtime libraries can handle - which would have to be more than 500 files in the code as it stands. Are you using IMAP heavily for many, many users? That's the only scenario I can think of that could result in Mercury running out of handles (short of the standard problem with anti-virus background scanners, but I assume you have disabled those on the Mercury queue and mailbox directories).

The best assistance you can give me to resolve this would be to download filemon or TaskInfo (www.iarsn.com), install it, wait until the problem occurs again, then use the output from those utilities to pinpoint the files that are being left open. Also, make sure that your antivirus package is NOT interfering with Mercury's queue and mailbox file access - all bets are off if you have left a background A/V scanner enabled; they can interfere with so many things at so many levels that they are nothing but a curse.

If it turns out that files ARE being left open, capture a list of them (I can tell a lot from the filename and extension), then either mail them to me offline, or post the list here.

Cheers!

-- David --

Thank you for replying so quickly David.

First of all, this is the third time this happens in over three years of using Mercury/32. So I will install filemon later this week, but hopefully it will take a year or so before I can report back to you.

I do not use IMAP at all, no AV package or anything like it on the Mercury machine, nor on the Pegasus mailboxes on Novell.

Just a thought on what you wrote about file handles: elsewhere on this forum I read that messages deleted by the new outgoing mail filter remain in the queue until Mercury is closed down. Could this mean that they take up a file handle? I recently started using the outgoing mail filter for deleting autoreplies to spam.

I hope you can come up with something - you may want to consider restarting Mercury when this condition occurs. 
I will do my best with filemon.

Bart

PS: I still love Mercury, even if it cheats on me occasionally.

I have the same problem as the OP. Mercury giving a serie (sometime a couple, sometime a good dozen) of the alias file sharing problem message in the Mercury core process window.

Mercury is running on a Windows server 2003 machine. It used to have an antivirus client active, but I removed it just to be sure it wasn't influencing Mercury (even if it did run for weeks without any problem with it active). After removal the problem seem to have lessened, but has not disappeared. As suggested in this thread I rinstalled and run TaskInfo, but I don't really know which section of the lenghty output I have to post. Or can I mail them somewhere?

Miscellaneous detail that have come to mind: IMAP is installed but not actually used by anyone (the users aren't aware of it), We dont have Pegasus clients but all MS Outlook 11 or 12, no Novell. Restarting the program seems to help for awhile.

What is weird is that I run on older machines the version 4.1 without any problem for years... And this modern machine fails me. Ah, technology...
 

install filemon from sysinternals to see if any other process is failing to release alias.mer. We've seen weird file lockings even from explorer itself this way, and it turned out that if you highlight files, select to see it's properties, you may in rare cases get file locks.

 You may also want to check out and disable opportunistic locking. F.ex. if you have antiviral clients, anti-spam, anti-phishing etc. that are enabled over the network and you share the roots, etc. the very same can happen. Only way of catching this is using filemon to only look at alias.mer

"Alias file sharing problem" *always* means that Mercury has run out of file handles. To explain: while Windows can have many thousands, or even hundreds of thousands of files open at any given time, individual programs almost always have much lower limits that are imposed on them by the software tools that were used to develop them. In Mercury, the limit is around 750 files open at any given time. Once the limit is exceeded, the process cannot open any further files.

Now, if you get a programming error where a file gets opened, but for whatever reason, never gets closed, then that's one of your 750 handles "lost" - you won't be able to re-use it. If the programming error happens frequently while the program runs, the program will eventually run out of available handles and will start behaving erratically (because it won't be able to open files it needs). In Mercury, the clearest symptom of this type of problem is the "Alias file sharing problem", because there really isn't any other reason why the alias file could fail to open.

Needless to say, I'm very interested in problems like this. They're very hard for me to reproduce in testing, because I can simply no longer test every possible usage scenario in the program (it's far too rich for that). The most helpful thing you can do to assist me in resolving problems like this is to try and work out what files are being opened but never closed. There are various tools, such as TaskInfo (http://www.iarsn.com/) which can show you this information for running processes. If you can provide me with the information I need, I will definitely attempt to fix it in a timely fashion.

That said, Bart (the original poster) and I have corresponded about this and I think we concluded that the problem in this case was to do with files not being closed when particular types of filtering rule were used. As best I can recall off the top of my head, I have now fixed this issue for Mercury v4.6.

Cheers!

-- David --

Since a day and half I don't see the error, but I can provide additional infos that came to mind: TaskInfo reported a huge number of handles in use during one of the 'accidents' (25,000+). The server is used for file sharing, but the mercury folder itself is out of the shared area. I use the popfile daemon coupled with it, so it could be some problem with it not releasing the mail files correctly, I guess. I'll keep you posted if I notice more connections between them.