I tried to see if there were any special circumstances that would trigger this, comparing two installations with rather different working environment. I got the same result with or without Spamhalter, Graywall, Clamwall or other daemons. It didn't occur more (or less) frequent after a restart. It appears to be somewhat load related, though: it's more likely to happen when there are a lot of messages coming in to core simultaneously.

It's not in any way a problem to have the archive program make sure it always uses a new filename. It was something of a shock though going from no duplicate filenames in a single day in 5 years (with I guess millions of archived emails) to getting a few hundred of them yesterday!

/Rolf 

I've encountered a difference in the policy handling in Mercury 4.62 that actually caused us a great deal of problems today. A command line archive copy program I've been using in different installations since 2002 suddenly started firing lots of policy exceptions after upgrading to the new Mercury version (hundreds of them).

I added some debug error messages to the program which revealed the reason: Mercury was re-using filenames in the ~X substitution variable, causing archive copying to fail as there already was a file with that name in the destination directory.

Earlier the ~X filename has always been unique, so this is obviously a change in version 4.6x. To get around this I've modified my program to change the destination filename if it's already used.

There may be other Mercury users that use the ~X filenames for archiving or other policy tasks, though, so I thought this needed pointing out.

/Rolf

Rolf, I've had a look at the code, and nothing has changed here for several years. I can only assume that what you are running into here is coincidental - that there's a particular combination of factors resulting in the same pseudo-random filename sequence being re-used.

That said, it was never really the intention that you should be able to make any specific assumptions about the randomness or lack of existence of the datafile filename, and the code *does* use an older version of my random filename generator which is much less random than later versions. It's absolutely no problem to change it to use the "more random" version, and I'll do that for the next version, but your modified approach (using your own filename) is probably a safe one in any event.

Cheers!

-- David --