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
On Mon, 20 Jan 2003, Mark Crispin wrote:
In my humble opinion:
RENAME was a bad idea, and should be removed from the protocol.
What is your advise to an author of an IMAP server that tries hard to
be as compliant as possible? ;)
Andy
--
Andreas Aardal Hanssen - Binc IMAP
On Tue, 21 Jan 2003, Andreas Aardal Hanssen wrote:
On Mon, 20 Jan 2003, Mark Crispin wrote:
In my humble opinion:
RENAME was a bad idea, and should be removed from the protocol.
What is your advise to an author of an IMAP server that tries hard to
be as compliant as possible? ;)
Lobby with
I believe the only safe implementation of RENAME is one that creates a new
mailbox, copies all messages to that new mailbox, and then deletes the
source mailbox. The client can do that just as easily as the server.
I agree. RENAME appears simple at first glance; in practice it has
turned out to
Mark Crispin wrote:
The idea behind RENAME was to have a command which would do a rename()
system call at the server end. That has been demonstrated to be an
ill-conceived idea. Not only doesn't this do the right thing with
UIDVALIDITY (a flaw that almost every server has), but Cyrus
Date: Tue, 21 Jan 2003 10:38:04 -0800 (Pacific Standard Time)
From: Mark Crispin [EMAIL PROTECTED]
[...]
I believe the only safe implementation of RENAME is one that creates a new
mailbox, copies all messages to that new mailbox, and then deletes the
source mailbox. The client can
On Tue, 21 Jan 2003, Lawrence Greenfield wrote:
I believe that the reference argument to LIST can't be fixed. Will you
join me in lobbying to remove it?
Nonsense. The reference argument to LIST works, and works very well.
The cost of re-opening that can of worms will be mandatory CWD and PWD
Timo Sirainen [EMAIL PROTECTED] writes:
If the client does the != test instead of the = test, then it's a
client that allows more than the RFC allows. I'm not quite sure of the
implications of this, but I can not imagine why a client would use !=
instead of =.
I can't imagine why client
In my humble opinion:
RENAME was a bad idea, and should be removed from the protocol.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Can an IMAP server implement RENAME in such a way that it is compliant
with IMAP4rev1?
I am thinking in particular with what was mentioned earlier about the
sequence
RENAME a b
CREATE a
DELETE a
RENAME b a
...in which the UIDVALIDITY.UID criteria no longer holds water if the IMAP
server
Andreas Aardal Hanssen wrote:
Can an IMAP server implement RENAME in such a way that it is compliant
with IMAP4rev1?
I am thinking in particular with what was mentioned earlier about the
sequence
RENAME a b
CREATE a
DELETE a
RENAME b a
...in which the UIDVALIDITY.UID criteria no
Oops, I've hit Send button too soon...
Andreas Aardal Hanssen wrote:
Can an IMAP server implement RENAME in such a way that it is compliant
with IMAP4rev1?
I am thinking in particular with what was mentioned earlier about the
sequence
RENAME a b
CREATE a
DELETE a
RENAME b a
...in
On Sun, 2003-01-19 at 23:30, Andreas Aardal Hanssen wrote:
Like I said, I don't see any requirement for UIDVALIDITY to _grow_. It
has to be _different_.
If unique identifiers from an earlier session fail to persist to this
session, the unique identifier validity value MUST be greater than
On 20 Jan 2003, Timo Sirainen wrote:
On Sun, 2003-01-19 at 23:30, Andreas Aardal Hanssen wrote:
If there wasn't the requirement to grow, there would be no need to
remember any of the old UIDVALIDITY values, since they could never
conflict (with my previous plan).
You agree that the problem arises
On 20 Jan 2003, Timo Sirainen wrote:
Simple. Use a global or user-global UIDVALIDITY counter. How exactly
that is done is implementation problem. I was thinking of a .uidvalidity
file which contains it. It would initially begin with time(), but after
that it would grow one at a time. That way it
27 matches
Mail list logo
