Re: [Courier-imap] courierpop3dsizelist and NFS

[Sam V. <mr...@co...>]

Luca Di Vizio writes:

> Il 01/05/2012 01:00 PM, Sam Varshavchik ha scritto:
> > Luca Di Vizio writes:
> >
> >> The issue we found is that when fopen() on courierpop3dsizelist fails,
> >> we have "duplicated" UIDs for the same message. For example:
> >>
> >> 1325511998.P3416Q2.smtpecn4,S=12873554:2, 13040825 278:1325511285
> >> =>
> >> 1325511998.P3416Q2.smtpecn4,S=12873554:2, 13040825 0:1325511285
> >> (convert_v0=1 when fopen() fails?)
> >>
> >> So The same message will have two different UIDs: old format and new
> >> format.
> >
> > Not in the same file, at the same time, it wouldn't. It does not get
> > duplicated, it gets changed.
>
> I meant changed (my english is quite poor, sorry :D).
>
>  From RFC 1939 it seems that UID should be the same in every session:
>
> The unique-id of a message is an arbitrary server-determined
> string, consisting of one to 70 characters in the range 0x21
> to 0x7E, which uniquely identifies a message within a
> maildrop and which persists across sessions.  This
> persistence is required even if a session ends without
> entering the UPDATE state.  The server should never reuse an
> unique-id in a given maildrop, for as long as the entity
> using the unique-id exists.
>
> A lot of users use this capability to process the messages :/

Then something needs to be done to un-break NFS, so that you have a reliable  
filesystem that permits it to happen. If a file can't be opened, there's  
nothing that a process can do about it.