GNOME Bugzilla – Bug 205095
evolution fails when folders are on fileystem with no locks
Last modified: 2013-09-10 14:02:36 UTC
Package: Evolution Priority: Normal Version: 0.11 Synopsis: Evolution 0.11 crashes when user's home is on NFS Bugzilla-Product: Evolution Bugzilla-Component: Mailer Description: On linux-2.4 based systems with knfsd (and lockd running), evolution 0.11 will crash it's mail component with the error message: -------------------------- Error while 'Retrieving message 1': Failed to get lock using fcntl(2): No locks available -------------------------- This happened right after starting up evolution for the first time, and clicking on the pre-inserted "Welcome..." e-mail. After this message, another one follows: -------------------------- Ooops! The view for 'evolution:/local/Inbox' have died unexpectedly. This probably means that the mail component has crashed. -------------------------- All you need in order to reproduce it is to have your user home directory mounted locally via NFS, exported from another machine. I think. :) Let me know if you need more info. Unknown reporter: joe@sysorb.com, changed to bugbuddy-import@ximian.com.
*** bug 205192 has been marked as a duplicate of this bug. ***
Fixed the crash (it was an assertion failure), so i'm marking it down from blocker (it just requires compilation options to get to work). Now the problem is how to make this run-time configurable, on a per-folder basis. Maybe we should only use .locks for our own storage areas.
*** bug 204996 has been marked as a duplicate of this bug. ***
*** bug 205216 has been marked as a duplicate of this bug. ***
*** bug 206115 has been marked as a duplicate of this bug. ***
*** bug 203099 has been marked as a duplicate of this bug. ***
Hey Notzed, I'm not able to use Evo because of this bug, could you pleaze work on this one? Regards, Rolo
*** bug 208446 has been marked as a duplicate of this bug. ***
*** bug 209039 has been marked as a duplicate of this bug. ***
*** bug 209581 has been marked as a duplicate of this bug. ***
*** bug 209857 has been marked as a duplicate of this bug. ***
Re-titling to make it show up more clearly.
*** bug 208909 has been marked as a duplicate of this bug. ***
*** bug 210122 has been marked as a duplicate of this bug. ***
notzed: is this the same as bug 206335?
*** bug 208811 has been marked as a duplicate of this bug. ***
You have to recompile with --enable-file-locking=no This will enable it to work with nfs. I'll try to think up a way that it can auto-detect this. The problem is most system calls return the same for either running out of locks or locking not available on the filesystem. This bug is unrelated to 6335 which is a packaging problem/different issue. Retitling as this has nothign to do with permissions.
I've put a change into the fcntl locking code that will now say it 'locked ok', even if it got an error, if that error says 'we dont support locking'. 1 problem, this is usually the same error that says 'we've run out of locks'. But i suppose it should be ok, generally, particularly since we .lock as well anyway. It is also somewhat system specific, but linux, solaris, *bsd kernels should hopefully work with what i've done. But i have not tested it at all, so someone test this.
*** bug 210364 has been marked as a duplicate of this bug. ***
*** bug 217306 has been marked as a duplicate of this bug. ***
We have a dup of this from 1.0; notzed, your thoughts?
*** bug 228233 has been marked as a duplicate of this bug. ***
*** bug 229063 has been marked as a duplicate of this bug. ***
*** bug 229064 has been marked as a duplicate of this bug. ***
*** bug 240147 has been marked as a duplicate of this bug. ***