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,
please remove me from you list.
--
-
For information about this mailing list, and its archives, see:
http://www.washington.edu/imap/imap-list.html
-
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, July 08, 2004 5:24 AM
Subject: unscript
please remove me from you list.
--
-
For information about this mailing list, and its
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: 08 July 2004 15:57
To: Andreas Aardal Hanssen
Cc: IMAP protocol mailing list
Subject: Re: File Locking
Andreas Aardal Hanssen [EMAIL PROTECTED] wrote:
It looks like a good solution, but it has a flaw;
Every IMAP list message contains the proper unsubscribe instructions in
the message header: the List-Help, List-Subscribe, List-Unsubscribe,
List-Owner, and List-Post header lines. Please use these instructions.
Please do not send unsubscribe messages to the mailing list, nor to me
- 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 to
On Thu, 8 Jul 2004 [EMAIL PROTECTED] wrote:
That would then make me assume that though our IMAP server appears to be
working it must be silently working incorrectly, because we are accessing
IMAP's data store from NFS. What symptoms would I experience when a flock()
lock erroneously succeeds?
If
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 to
- 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
The reason for this is that there is more than synchronizing locks. It is
also necessary to synchronize inode status and data. It is a requirement
that a change anywhere in the file be instantaneously (atomicly) reflected
in all other members in the cluster. This requires an *extremely*
On Fri, 2004-07-09 at 01:23, [EMAIL PROTECTED] wrote:
I'm confident that if Lustre does what it says it should work with IMAP just
like IMAP works over a local volume. I'm still skeptical that they can boast
this, but if it turns out that IMAP won't work over Lustre I would suggest
that IMAP
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
20 matches
Mail list logo
