[Kroupware] Re: [ot] maildir & locking (was: Re: Web interface frontend)

[Marc Mutz]

--Boundary-02=_ZIfl9oWR09v56a5
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

On Saturday 28 September 2002 14:47, konold@erfrakon.de wrote:
> On Fri, 27 Sep 2002, Marc Mutz wrote:
<snip>
> > Status updates are mv's, which are atomic on
> > almost all OSs.
>
> mv's are only atomic on mosts OSs on a single local filesystem. E.g.
> if /tmp and your maildir repository live on different filesystems
> mv's are not atomic anymore. Having /tmp on a separate fs is very
> common in larger setups.

A maildir is comprised of three subdirs: tmp/, cur/, new/. I said tmp/,=20
not /tmp.

> >  Adding a new mail is done via assembling it in tmp/,
> > then mv'ing it to new/. Changing a mail's content is done by
> > writing the new version to tmp/, then mv'ing it over the old one.
> >
> > Where do you see locking issues here?
>
> Imagine that two clients access the same maildir repository on a nfs
> server.
>
> How do you guarantee that there is no naming collision if both are
> simultaneously creating new messages?
<snip>

There is an algorithm to create those names uniquely. It involves the=20
time, the pid and random numbers. See the maildir page at=20
http://cr.yp.to/proto/maildir.html.

So the chance of that happening is very dim:
=2D both processes have to try in the same second
=2D both processes have to run with the same pid.
=2D both processes need to draw the same (~24bit?) random number.

If you are creating messages on more than one host, the obvious solution=20
is to introduce the originating machine's id into the algorithm somehow=20
=2D e.g. as part of the third dot-separated part before the colon or as a=20
pid-modifier (<pid>0..<pid>9).

Marc

=2D-=20
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.      -- Benjamin Franklin

--Boundary-02=_ZIfl9oWR09v56a5
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)

iD8DBQA9lfIZ3oWD+L2/6DgRAtYIAJ9Hgl3Z9lVjODRdLqhiF2YKIEaAKACfebqY
78b6rJrWbKW4YTLWLVWV7sA=
=6vR1
-----END PGP SIGNATURE-----

--Boundary-02=_ZIfl9oWR09v56a5--