and kill all the users' imapd processes for them to get their
mailboxes back again.
What mailbox format are you using? This read-only behavior sounds like
traditional UNIX mailbox format.
Unexpected file locking failure: Deadlock situation detected/avoided
This is not a good thing; it means
I do want to exterminate these problems. I had hoped that 2006j would
have done so. Apparently it did not, but please make sure that you are
running the distribution version and not one of the development snapshots.
The situation related to signal handling is in the attempt to save changes
of lines like this:
Unexpected file locking failure: Deadlock situation detected/avoided
We're not using NFS, just normal local disks, and we've never had this
trouble with imap before. The machines are suns, uname -a gives this:
SunOS mstore5 5.8 Generic_108528-23 sun4u sparc SUNW,Sun-Blade-100
I'm
Mark,
Will file locking for mbx-formatted folders work correctly when multiple
users are accessing the same mbx folder at the same time via UW IMAP, but
though different hard-linked folder name points in the directory tree?
We are using Linux kernel v2.4+
Thank you,
-Erik Kangas
LuxSci.com
On Wed, 7 Jul 2004, Tim Showalter wrote:
moving a user without his client being aware of it. I like this method;
it's cute, and solves a lot of the problems without a hell of a lot of
work. (I've never tried it personally, though.)
It looks like a good solution, but it has a flaw; mining for
Andreas Aardal Hanssen wrote:
On Wed, 7 Jul 2004, Tim Showalter wrote:
moving a user without his client being aware of it. I like this method;
it's cute, and solves a lot of the problems without a hell of a lot of
work. (I've never tried it personally, though.)
It looks like a good solution,
Andreas Aardal Hanssen [EMAIL PROTECTED] wrote:
It looks like a good solution, but it has a flaw; mining for the existance
of email addresses is done with a simple DNS lookup.
A wildcard record would take care of that. Or, to make it less
detectable, lots of individual records, aliasing
- Original Message -
From: Mark Crispin [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Wednesday, July 07, 2004 6:05 PM
Subject: Re: File Locking
It means that flock() will succeed, having done nothing. Thus, the
application will think that there is an flock
- Original Message -
From: Mark Crispin [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, July 07, 2004 6:09 PM
Subject: Re: File Locking
On Wed, 7 Jul 2004 [EMAIL PROTECTED] wrote:
You say IMAP Server is based on C-Client and c-client locking is only of
interest
NFS has been
fixed - besides isn't that what the nfslock daemon is for?
I hope not! Those lock-over-NFS daemons are for fcntl() locking only, and
THEY DO NOT WORK WORTH A DAMN! It is a *feature* that flock() does not
use those broken daemons.
To me this means that the documentation on file
On Thu, 8 Jul 2004 [EMAIL PROTECTED] wrote:
I may be revealing my ignorance again, but I think we were using
qpopper before we even decided to use IMAP at all, that had problems over
NFS because it locks, makes a copy and if you are saving messages on the
server copies it back. All that happening
From: Mark Crispin [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Thursday, July 08, 2004 11:00 AM
Subject: Re: File Locking
On Thu, 8 Jul 2004 [EMAIL PROTECTED] wrote:
I may be revealing my ignorance again, but I think we were using
qpopper before we even decided
- Original Message -
From: Mark Crispin [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Thursday, July 08, 2004 10:54 AM
Subject: Re: File Locking
Again - from what I understood, this issue with flock() over NFS has
been
fixed - besides isn't that what the nfslock
On Thu, 8 Jul 2004 [EMAIL PROTECTED] wrote:
So if we were to insist on remote storage we would have to modify IMAP
server source to do fcntrl instead of flocks where necessary and it still
wouldn't work because lock files can't be counted on.
More importantly, you MUST use .lock files with NFS in
On Thu, 2004-07-08 at 22:25, Mark Crispin wrote:
Each user has his own DNS name for his server. In my case, it is
mrc.deskmail.washington.edu, and that is the only system that I connect
to. Some number of users are on the same physical CPU. mrc.deskmail is
currently on a machine called
try to figure
out a way to get IMAP POP SMTP etc file locking working over a similar
distributed file system. For the reasons mentioned above I feel that many
would find that useful.
server developers and file system developers alike try to figure
out a way to get IMAP POP SMTP etc file locking working over a similar
distributed file system. For the reasons mentioned above I feel that many
would find that useful.
That is all specific to how IMAP server's internal mailbox
On Thu, 8 Jul 2004, Timo Sirainen wrote:
Doesn't that mean that a user is located only in a single server, so in
case it breaks, the user can't read mail until admin has fixed the
problem by restoring mails from backups and moved the accounts to new
server?
As opposed to having all users located
On Fri, 2004-07-09 at 02:23, Mark Crispin wrote:
Unless the account is mirrored between multiple servers in realtime as
well (how?), user can also lose mails. Better than everyone's mail
breaking, but I'd prefer transparent failovers without any data loss.
Why do you believe that an IMAP
On Fri, 9 Jul 2004, Timo Sirainen wrote:
I didn't say anything about NFS. Filesystems clustered over multiple
separate computers providing automatic failover if a few of the
computers die are more interesting. Of course that assumes that they
work correctly - I don't have personal experience with
On Wed, 7 Jul 2004 [EMAIL PROTECTED] wrote:
I've been doing some research on file locking for mail systems and have
noticed in several places mention made to IMAP [Not needing file
locking].
Any place that says such a thing is uninformed (at best).
Although the IMAP protocol itself has
On Jul 7, 5:27pm, [EMAIL PROTECTED] wrote:
Subject: Re: File Locking
are cutsiepop and sendmail two of programs that you refer to as non c-type
applications
I'm guessing that you may mean cusipop, from CUSI in the Netherlands?
As far as I know cusipop does not use c-client.
are cutsiepop and sendmail two of programs that you refer to as non c-type
applications
By cutsiepop, do you mean cucipop? C-type doesn't make any sense
(they're written in C, but who cares). Do you mean c-client type?
Neither cucipop or sendmail are c-client applications, in that they do
not
23 matches
Mail list logo
