I will complain :-)

Well.

I have the same problem here. From the moment I first time installed Mercury, year and so.

And it is a WONDERFUL PRODUCT but this little annoyance is just ... annoying :-)

When I start Mercury it fetches my emails via POP3 from outside mail server and delivers them locally to be read by IMAP client.

Of

FIRST fetch, no matter how many emails fetches - app. 1/4 messages get

stucked by "Transient error - job deffered for later processing".

Others are delivered but this 1/4 stays in "Pending" state. After some

time(?) they get delivered to. Don't know about this "time" parameter

but I would say it is something about 20 mins or so.

At that time many files in QUEUE have  this "File rename failure for xxxxxx" message.

Now, I have NO AV program, NO any other  program that would access files and interfere with mercury. No NOTHING.

Frankly, I would plainly say there is a bug somewhere so please fix it and make this great software even better.

Hi

Mercury generated this error when trying to deliver an email:

Could you paste some info from your logs - we need to know what module, and if you can attach a screen shot that would help more

Whoops, sorry.

It was the Core module attempting to deliver mail to a mailbox:

I assume the file rename message was in a delivery failure notice sent to the sender?

Is there any anti-virus software on the server that might be blocking Mercury's access to files?

/Rolf
 

Hi Rolf

The sender may have got this message (I'm afraid that I don't know), but the failure message was delivered to the default Admin account on our server to which all errors are sent.

There is anti-virus software on the server, but I doubt it is blocking access to any files. I've checked the AV logs, and nothing has been detected as being amiss.

Mercury needs exclusive access to work files, so Mercury directories should normally be excluded from real-time anti-virus scanning (at least queue directories and scratch directory).

/Rolf 

Thanks for your reply.

If anti-virus was restricting/blocking access to files, I would expect to see this problem more often and for it to be more widespread - i.e. affect other mailboxes. Today, Mercury generated another error for the same mailbox.

Can anyone tell me what causes this error, please? If I have that information, I may be able to troubleshoot this problem more effectively.

Thanks

Edit:

Just checked the anti-virus exclusions and the queue folder was already included. I've now added the scratch folder.

Edit2:

Just sent two emails from my web account - one to my work account and one to the affected account. Mine came through fine, the mail to the affected account was deferred again.

The rename error is caused when core is trying to rename a container file in the users directory and cannot.  The why is unknown just like when you would try to rename a file and could not.  Generally this happens though when some other application also has the file open, like the anti-virus program.  It also could be a rights problem to this users new mail directory.  In any case, try turning off the anti-virus scanning of the users new mail directories and all other Mercury/32 directories.

You can check for virus in the messages at the Mercury/32  level using ClamWall or a policy running your anti-virus program.

Thanks, Thomas

It was a permissions problem. I don't know how but the local administrator account (as opposed to the domain administrator account) had been removed from the mailbox folder's security permissions. I put it back, took ownership using the local admin account, then reset all permissions and now everything works again.

Thanks again.

I have the same kind of problem too here for some weeks - whenever I collect emails (at least I'm sure about the first poll after starting mercury), a couple of them stay "pending" with a "File rename failure" - a restart of mercury has no effect, though a logoff and re-logon with a new start of mercury "cleans up" (i.e. processes) the pending messages...

access rights to the mercury directories seem to be ok, and the \queue -directory as well as the user directories are explicitly excluded from any virus-scans...

any other ideas? 

[quote user="Devil505"]

I have the same kind of problem too here for some weeks - whenever I collect emails (at least I'm sure about the first poll after starting mercury), a couple of them stay "pending" with a "File rename failure" - a restart of mercury has no effect, though a logoff and re-logon with a new start of mercury "cleans up" (i.e. processes) the pending messages...

access rights to the mercury directories seem to be ok, and the \queue -directory as well as the user directories are explicitly excluded from any virus-scans...

any other ideas? 

[/quote]

Could be an actual rename problem where the receiver has hundreds of messages in the folder and Mercury/32 is having trouble writing the unique CNM file.  That said, I really suspect an anti-virus program interfering with the ability to write to a file it has created. What version of Mercury/32 are you running?  Are you running any anti-virus program against the mail directories?

If the problem is the same after restarting Mercury, but is fixed if you log out of Windows, then it would seem there is another process in your user environment that locks the file. Try deactivating your anti-virus software altogether and see if that helps, or check if there is some other process that might have a reason to open files in the Mercury directories.

/Rolf 

Do you have any behavioural analysis programs running? I use a behavioural analysis program on my home PC as well as a virus checker, and it has caused some unexpected problems. If you do use such a program, check the logs, and exclude winpm-32.exe from monitoring.

Check the 'Effective Permissions' tab in the folder's Security dialog and verify the local administrator has full rights to the folder and the files.

[quote user="Thomas R. Stephenson"]

Could be an actual rename problem where the receiver has hundreds of messages in the folder and Mercury/32 is having trouble writing the unique CNM file.  That said, I really suspect an anti-virus program interfering with the ability to write to a file it has created. What version of Mercury/32 are you running?  Are you running any anti-virus program against the mail directories?

[/quote]

First of all, thanks for the quick reply and sorry for my somewhat delayed one - I had to get and configure a new Laptop after my old one died the infamous "flexing death" on me - that process included a reinstalling of Mercury too with the most recent version from the web combined with the data/ config files of the previous installation (which had been the same version) - the problem still persists: after not having been able to pop my mails for a couple of days I performed a download of about 1500+ emails, nearly 800 of them remaining in a pending state - one slight twist to what I wrote before: it doesn't require a logoff/ login under Windows XP to Mercury being able to process some more pending emails, quitting Mercury for some time (20 minutes?) and starting it again usually leads to some of the pending emails being processed...

The number of emails doesn't seem to be much of a factor in general, even if i pop only about 30 emails, something between 1/4 - 1/2 of them will be pending - so far it seemed to affect the first pop only - consecutive pops in the same session don't seem to generate additional pending messages, nor do they clean up any of the initial pendings...

...the number of messages in the mail-directory usually is kept fairly low - I'm the only user and after the "initial pop of the day" I have Mercury deliver the emails quite regularly to my Pegasus instance (I don't use the Pegasus integration of Mercury 'cause I prefer to use a 3rd party anti-spam software)...

I noticed that pending problem fairly recently, somewhat in the last 2-3 month - never had any such problems before as far as I can tell, only I have no idea at all what changed in my system - there's a faint chance that the problem occurred only after upgrading/ patching Mercury to the recent version, but I'm not sure about the timing...

My  anti-virus solution (Avira) shouldn't be a problem - apart from explicitly excluding nearly every Mercury folder I checked that the same problem occurs even with the guard process disabled - access rights to the Mercury folders shouldn't be a factor neither - ownership and permissions are the same as to any other (non -protected) folder in the system...

If I would have to bet I'd  guess it's an algorithmic problem with the code responsible for the renaming - as there's the chance that this problem occurred only after upgrading to the recent version, I wonder if that part of the code underwent any changes...

Thanks again 

[quote user="Rolf Lindby"]

If the problem is the same after restarting Mercury, but is fixed if you log out of Windows, then it would seem there is another process in your user environment that locks the file. Try deactivating your anti-virus software altogether and see if that helps, or check if there is some other process that might have a reason to open files in the Mercury directories.

/Rolf 

[/quote]

 Tried switching off my antivirus software before the 1st pop (i.e. the one affected) with no noticeable difference - the problem persists...

Thanks anyway for the advice

[quote user="Greenman"]

Do you have any behavioural analysis programs running? I use a behavioural analysis program on my home PC as well as a virus checker, and it has caused some unexpected problems. If you do use such a program, check the logs, and exclude winpm-32.exe from monitoring.

Check the 'Effective Permissions' tab in the folder's Security dialog and verify the local administrator has full rights to the folder and the files.

[/quote]

I'm not aware of any behavioural analysis programs running here (apart from sending  the usual error-logs on program crashes to Microsoft and whatever Windows XP "calls home" to Redmond these days without the user knowing ;) ) - (effective) permissions/ access rights/ ownership of the folders in question look fairly normal to me - I didn't change them recently and the way they are (i.e. system-default) worked well for years

Thanks for the advice

If I would have to bet I'd  guess it's an algorithmic problem with the

code responsible for the renaming - as there's the chance that this

problem occurred only after upgrading to the recent version, I wonder

if that part of the code underwent any changes...

I really doubt this or there would be hundreds of people complaining.  There can be a delay in writing via the algorithm is a new mail directory contain thousands of message and Mercury core is having troubles finding a unique root for a CNM file but even there this one probably be only a one cycle delay.  This code has been tested with thousands of messages being received and delivered without any problems at all. In fact I just setup a test of 5000 messages ranging in size from 1000 to 4000 bytes being sent to a Mercury/32 system.  These went from one Mercury/32 system to another via MercuryE to MercuryS and they were all delivered to the user in ~18 minutes.  Even with 5000 messages being delivered to a single account there were no delays.

I'm still betting there is there is something accessing the files in the Mercury or the TEMP/TMP  directories during the create/write process that is causing the delay. 

[quote user="Thomas R. Stephenson"]

If I would have to bet I'd  guess it's an algorithmic problem with the

code responsible for the renaming - as there's the chance that this

problem occurred only after upgrading to the recent version, I wonder

if that part of the code underwent any changes...

I really doubt this or there would be hundreds of people complaining.  [...]

[/quote]

You surely have a point -  but then again there's always the exceptions that makes the programmer seriously scratch his/ her head wondering what's different on THAT or THESE specific machines...

[quote user="Thomas R. Stephenson"]

There can be a delay in writing via the algorithm is a new mail directory contain thousands of message and Mercury core is having troubles finding a unique root for a CNM file but even there this one probably be only a one cycle delay.  This code has been tested with thousands of messages being received and delivered without any problems at all. In fact I just setup a test of 5000 messages ranging in size from 1000 to 4000 bytes being sent to a Mercury/32 system.  These went from one Mercury/32 system to another via MercuryE to MercuryS and they were all delivered to the user in ~18 minutes.  Even with 5000 messages being delivered to a single account there were no delays.

I'm still betting there is there is something accessing the files in the Mercury or the TEMP/TMP  directories during the create/write process that is causing the delay. 

[/quote]

I just tried a "clean new setup from scratch " of mercury, as in the past I usually copied all settings/ rules/ filters etc. to any newly set up mercury - the aim was to get a "clean" config/ ini-file - the problem persisted though...

I tried SysInternals ProcMon to see if there's any clue in the file access logs as to what's happening - the logs didn't make me any wiser though as i simply don't see any obvious problems, not knowing what i should look for specifically - nor did SysInternal's ProcExp indicate any irregular task accessing the mercury directories - other than that I'm somewhat out of ideas as to what to do to find out if there are any other tasks interfering - I'm somewhat reluctant to offer to send you the ProcMon log as it might be somewhat time consuming to work through nearly 2mb of log-data for such a rare problem...

I might state though, that mercury and its directories are located on a TrueCrypt device, though that never had been a problem with mercury nor any other application for years...

...most possible tasks that were running wild and might have interfered should have been eliminated by the fact that the new laptop implied a completely new setup of windows XP Pro too, even though the programs installed are of course fairly similar to the previous installation...

The only other software I'm aware of that might interfere with disc-access in a broader sense are O&O Clever Cache and O&O Defrag who have automatic background processes running - and I suspect processes that do more than just maintain the tray icons...

Thanks anyway for your time & attention so far

I've been under a spam bounce attack for about a week and I've started seeing hundreds of these errors for a spam mailbox.  When I clean it out they go away, then as it fills up they get more frequent.  I'm convinced there is no other program involved, its strictly a Mercury problem, due either to running out of file handles or just simple file name collisions.  I had about 9K messages in the spam folder this morning and saw hundreds of these errors.  As soon as the folder is trimmed down to 100 messages or less the errors go away entirely or are reduced to just a few an hour.  When the folder has thousands of emails you see hundreds of "Core: File rename failure for 'spam'" messages displayed.  I lean toward the filename collision because even when its puking out messages for the spam folder left and right you never see a message for any other mailbox as I would expect if it was running out of handles.