RENAME, on the other hand, is broken on almost all servers.
Maybe. But it is not impossible to fix RENAME in servers staying complaint
with IMAP4rev1.
And I don't buy the argument that a server can't store 4bytes UIDVALIDITY
somewhere when mailbox is deleted/renamed.
The Cyrus server
Andreas Aardal Hanssen writes:
And I don't buy the argument that a server can't store 4bytes
UIDVALIDITY somewhere when mailbox is deleted/renamed.
Do you understand the problem with UIDVALIDITY and RENAME? Not only do
you have to store your 4 bytes, but you will have to store all
UIDVALIDITY
Andreas Aardal Hanssen [EMAIL PROTECTED] writes:
On Wed, 22 Jan 2003, Alexey Melnikov wrote:
RENAME, on the other hand, is broken on almost all servers.
Maybe. But it is not impossible to fix RENAME in servers staying complaint
with IMAP4rev1.
Compliant is one thing, but bumping UIDVALIDITY
Andreas Aardal Hanssen wrote:
On Wed, 22 Jan 2003, Alexey Melnikov wrote:
RENAME, on the other hand, is broken on almost all servers.
Maybe. But it is not impossible to fix RENAME in servers staying complaint
with IMAP4rev1.
Compliant is one thing, but bumping UIDVALIDITY for source and
On Wed, 22 Jan 2003, Alexey Melnikov wrote:
I am taking this offline to clarify some stuff...
Andreas Aardal Hanssen wrote:
Which means that RENAME in practise will be _slower_ than
create, copy, delete.
Please, explain how this follows.
I wrote
Compliant is one thing, but bumping UIDVALIDITY
Simon Josefsson wrote:
Andreas Aardal Hanssen [EMAIL PROTECTED] writes:
On Wed, 22 Jan 2003, Alexey Melnikov wrote:
RENAME, on the other hand, is broken on almost all servers.
Maybe. But it is not impossible to fix RENAME in servers staying complaint
with IMAP4rev1.
Compliant is one
Andreas Aardal Hanssen wrote:
If they do need to grow, server would have to remember the last
UIDVALIDITY for deleted mailboxes, so RENAME could check if the
UIDVALIDITY must be changed. I don't like that behaviour. It's very
unnecessary and requires permanent space for deleted mailboxes.
On Wed, 22 Jan 2003, Alexey Melnikov wrote:
Andreas Aardal Hanssen wrote:
If they do need to grow, server would have to remember the last
UIDVALIDITY for deleted mailboxes, so RENAME could check if the
UIDVALIDITY must be changed. I don't like that behaviour. It's very
unnecessary and requires
Andreas Aardal Hanssen writes:
What happens if the alternative UIDVALIDITY log file gets messed up?
If the server's persistent storage is messed up, every guarantee breaks.
One example among dozens: If the server's UIDNEXT storage is
hand-edited, the UID grows guarantee is broken.
--Arnt
Andreas Aardal Hanssen writes:
On Wed, 22 Jan 2003, Arnt Gulbrandsen wrote:
Andreas Aardal Hanssen writes:
What happens if the alternative UIDVALIDITY log file gets messed up?
If the server's persistent storage is messed up, every guarantee
breaks. One example among dozens: If the server's
Hi Andreas,
--On Wednesday, January 22, 2003 12:58:39 PM +0100 Andreas Aardal Hanssen
[EMAIL PROTECTED] wrote:
| Compliant is one thing, but bumping UIDVALIDITY for source and
| destination mailboxes when renaming means that most offline clients have
| to re-scan the folder and download
On Wed, 22 Jan 2003, Cyrus Daboo wrote:
It seems to me that the problem here is the requirement to keep the
UIDVALIDITY the same when doing RENAME.
Where is that required? What's required is that the last-assigned UID has
to be saved, unless the UIDVALIDITY changes.
I propose the following
Mark Crispin wrote:
On Tue, 21 Jan 2003, Ken Murchison wrote:
Not only doesn't this do the right thing with
UIDVALIDITY (a flaw that almost every server has), but Cyrus doesn't even
Cyrus maintains UIDVALIDITY.
do the RENAME in an atomic fashion
Does Cyrus change the UIDVALIDITY
13 matches
Mail list logo
