On Wed, 22 Jan 2003, Cyrus Daboo wrote:
>Hi Andreas,
>--On Wednesday, January 22, 2003 12:58:39 PM +0100 Andreas Aardal Hanssen
><[EMAIL PROTECTED]> wrote:
>the copy destination mailbox to determine the UIDs assigned to the copied
>messages unless the server supports UIDPLUS (and quite a few do n
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 t
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
On Wed, 2003-01-22 at 12:22, Cyrus Daboo wrote:
> I propose the following solution: remove that constraint and require the
> renamed mailbox to get a new UIDVALIDITY value as if it were simply being
> created. However, the message UIDs MUST remain the same and the server
> SHOULD return the new
It seems to me that the problem here is the requirement to keep the
UIDVALIDITY the same when doing RENAME. That effectively forces the server
to cache UIDVALIDITY for mailboxes for all time to avoid a clash.
I propose the following solution: remove that constraint and require the
renamed mailb
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 heade
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 UI
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 UIDNEXT storage is
>hand-edited,
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
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
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 mailbox
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.
> >
> >
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 UIDVA
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 sour
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 UI
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
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 destination
mailboxes when renaming
> 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 (includ
18 matches
Mail list logo
