KMail and cifs userhomes crashes

[Ingo Klöcker]

On Monday 12 November 2007, Wilhelm Meier wrote:
> Am Samstag, 10. November 2007 schrieb Ingo Klöcker:
> > > Hi,
> > >
> > > we are using cifs userhomes mounted from a samba server.
> > >
> > > All is well exept for kmail. kmail crashes reproducible with
> > > segv(!).
> > >
> > > If we try this on the serverside with the local ext3-fs as
> > > userhome it works. Strange enough: if we then use this userhome
> > > over the samba/linx-cifs mount, it works also.
> > >
> > > We use unix-extensions for samba and the serverino option to make
> > > kde happy (links, sockets)

I'm a bit confused. If the server runs Linux (as the local ext3-fs
suggests) then why do you export the userhomes via cifs? Why not use
nfs (probably additionally to cifs if cifs is necessary for serving Windows
clients)?

> > > We tried: linux-cifs-1.49/1.50c and debian/samba stable and
> > > testing, kmail 1.9.7
> > >
> > > A kmail trace is attached.
> >
> > The trace is not very useful because it does not follow the fork of
> > the kmail process. Please run kmail with the --nofork option and
> > try again.
>
> please find the strace with --nofork and the gdb-output attached.

Thanks. The relevant section reads:

We look for the sent-mail folder:

> access("/home/diana.krall/.kde/share/apps/kmail/mail/sent-mail", F_OK) = -1 ENOENT (No such file or directory)
> access("/home/diana.krall/.kde/share/apps/kmail/mail/sent-mail/new", F_OK) = -1 ENOENT (No such file or directory)
> access("/home/diana.krall/.kde/share/apps/kmail/mail/sent-mail/cur", F_OK) = -1 ENOENT (No such file or directory)
> access("/home/diana.krall/.kde/share/apps/kmail/mail/sent-mail/tmp", F_OK) = -1 ENOENT (No such file or directory)

It does not exist, so we create it.

> mkdir("/home/diana.krall/.kde/share/apps/kmail/mail/sent-mail", 0700) = 0
> mkdir("/home/diana.krall/.kde/share/apps/kmail/mail/sent-mail/new", 0700) = 0
> mkdir("/home/diana.krall/.kde/share/apps/kmail/mail/sent-mail/cur", 0700) = 0
> mkdir("/home/diana.krall/.kde/share/apps/kmail/mail/sent-mail/tmp", 0700) = 0

Now we open (and create) the index file. (Hmm, this does not really make
much sense.)

> umask(077)                              = 022
> open("/home/diana.krall/.kde/share/apps/kmail/mail/.sent-mail.index", O_RDWR|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 11
> utime("/home/diana.krall/.kde/share/apps/kmail/mail/sent-mail", NULL) = 0
> utime("/home/diana.krall/.kde/share/apps/kmail/mail/.sent-mail.index", NULL) = 0
> utime("/home/diana.krall/.kde/share/apps/kmail/mail/.sent-mail.index.ids", NULL) = -1 ENOENT (No such file or directory)
> umask(022)                              = 077
> fcntl64(11, F_SETFD, FD_CLOEXEC)        = 0

Then we write the new (and empty) index of the sent-mail folder. The index
is written to a temporary file and this file is then renamed.

First a possibly existing old temporary file is deleted.

> unlink("/home/diana.krall/.kde/share/apps/kmail/mail/.sent-mail.index.temp") = -1 ENOENT (No such file or directory)
> utime("/home/diana.krall/.kde/share/apps/kmail/mail/sent-mail", NULL) = 0

Then a new temporary file is created and opened for writing,

> umask(077)                              = 022
> open("/home/diana.krall/.kde/share/apps/kmail/mail/.sent-mail.index.temp", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 12
> umask(022)                              = 077
> fstat64(12, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
> mmap2(NULL, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb5927000

the (empty) index is written,

> write(12, "# KMail-Index V1506\n\0\10\0\0\0xV4\22\4\0\0"..., 33) = 33
> _llseek(12, 0, [33], SEEK_CUR)          = 0
> fsync(12)                               = 0

and the temporary file containing the empty index is closed.

> close(12)                               = 0
> munmap(0xb5927000, 16384)               = 0

Now we try to replace the (old) index file with the newly created index
file (with rename()).

> rename("/home/diana.krall/.kde/share/apps/kmail/mail/.sent-mail.index.temp", "/home/diana.krall/.kde/share/apps/kmail/mail/.sent-mail.index") = -1 EINVAL (Invalid argument)

Renaming fails probably because the old index file is still open. Windows
file systems do not allow renaming open files. OTOH, according to
'man 2 rename' renaming should not fail. And if the server is indeed a
Linux machine then renaming shouldn't be a problem.

Next we close the old index file and try to open the new index file.
This does also fail. This is really odd because the documentation of
rename() clearly states:
 "If newpath exists but the operation fails for some reason rename()
  guarantees to leave an instance of newpath in place."

This does not seem to be the case here.

> close(11)                               = 0
> open("/home/diana.krall/.kde/share/apps/kmail/mail/.sent-mail.index", O_RDWR|O_LARGEFILE) = -1 ENOENT (No such file or directory)
> write(2, "kmail: kmfolderindex.cpp:201: vi"..., 108kmail: kmfolderindex.cpp:201: virtual int KMFolderIndex::writeIndex(bool): Assertion `mIndexStream' failed.) = 108

KMail is then terminated because of the problem with the index file.

So we have two problems:
a) Replacing the old index file with the new index file (with rename())
   fails although it should not fail.
b) KMail does not handle the problem gracefully.

Conclusion:
Due to the above problems it is most likely currently not possible to use
cifs mounted shares. Apart from those problems there might be another
problem preventing the usage of cifs mounted shares for mail storage in
maildir format: In the maildir format the colon (':') is used in filenames,
but the colon cannot be used in filenames on Windows file systems (and
the same is probably true for cifs mounted directories).

I'm sorry that I cannot give you a more satisfying answer.


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdepim-bugs/attachments/20071112/61f64d71/attachment.sig>