Re: Locking strategies and MAILPATH

2002-07-23 Thread Vincent Lefevre

On Mon, Jul 22, 2002 at 22:25:58 -0500, Derrick 'dman' Hudson wrote:
 On Mon, Jul 22, 2002 at 04:21:24PM +0200, Vincent Lefevre wrote:
 | On Mon, Jul 22, 2002 at 08:58:42 -0500, Derrick 'dman' Hudson wrote:
 |  On Mon, Jul 22, 2002 at 09:39:52AM +0200, Vincent Lefevre wrote:
 |  | I prefer to keep the mbox format for these mailboxes, because this
 |  | makes easier for other operations (like grepping or copying them).
 |  
 |  grep -r
 |  cp -r
 |  
 |  How does maildir inhibit those operations?
 | 
 | I haven't said that they were inhibited, I have said that using the
 | mbox format makes things easier. Sometimes, I need an interactive cp.
 
 Interactive cp?  Is that like using debugfs to copy inodes manually?
 (yes, that's joke, but I really don't know what can be interactive
 about cp)

cp -i

In fact, I use that by default. With the mbox format, I can answer for
each mailbox. Here, I would have to do that for every message! This is
not acceptable.

 | And how can cp -r (or scp -r) remove files from the destination
 | mailbox?
 
 *Those* commands don't, the 'rm' command does :-).

It can't. I recall that the task is to *copy* one or several mailboxes
(locally or through the network) with only one command.

 | Indeed, I sometimes delete messages from mailboxes.
 
 Is this always one-sided?  Or can you received/delete messages from
 either side and then want to sync them?

Always one-sided (but the side isn't always the same), i.e. only one
side has changes.

 If it is the former you can fairly easily script it with varying
 amounts of efficiency.  For example, just 'rm -rf' the folder on the
 destination and 'scp -r' to update it.

I don't like doing rm -rf. It is too dangerous (easy to delete the
wrong mailbox...). And AFAIK, I can't remove files with scp or a
similar command. I don't see how it could be easily scripted.

 In the latter case you need a program that understands mail folders
 (regardless of whether you use mbox or maildir) to properly sync the
 two folders.

Well, not my case.

 Perhaps a better solution is to use imap and have just one folder
 store.  (*perhaps*)

No, the network isn't always reachable, that's a reason why I need to
copy mailboxes (and for speed and backup reasons too).

 Can the limit function operate on message bodies?

Of course -- very useful!

 From what I've seen it seems to operate on the subject only (or
 certain other headers and properties if you use the right tilde
 magic).

For the body: ~b

-- 
Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA



Re: Locking strategies and MAILPATH

2002-07-22 Thread David Clarke

On Mon, 22 Jul 2002, Vincent Lefevre wrote:
 Note that my only spool mailbox is an IMAP mailbox. But I need a locking
 strategy for the postpone and archive mailboxes (under NFS). As fcntl is
 not reliable here, I think I'll disable it and use dotlocking only.
 

Perhaps try maildir mailboxes for the mailboxes on NFS, that should help
prevent problems with locking.

David

-- 
Two wrongs don't make a right, but three lefts do.



Re: Locking strategies and MAILPATH

2002-07-22 Thread Vincent Lefevre

On Mon, Jul 22, 2002 at 16:49:09 +1000, David Clarke wrote:
 Perhaps try maildir mailboxes for the mailboxes on NFS, that should help
 prevent problems with locking.

I prefer to keep the mbox format for these mailboxes, because this
makes easier for other operations (like grepping or copying them).
They are not incoming mailboxes, so I think that locking isn't really
important, just a precaution.

-- 
Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA



Re: Locking strategies and MAILPATH

2002-07-22 Thread Derrick 'dman' Hudson

On Mon, Jul 22, 2002 at 09:39:52AM +0200, Vincent Lefevre wrote:
| On Mon, Jul 22, 2002 at 16:49:09 +1000, David Clarke wrote:
|  Perhaps try maildir mailboxes for the mailboxes on NFS, that should help
|  prevent problems with locking.
| 
| I prefer to keep the mbox format for these mailboxes, because this
| makes easier for other operations (like grepping or copying them).

grep -r
cp -r

How does maildir inhibit those operations?  I actually find maildir
better for grepping because grep tells me which file (message) the
match was found in.  Then I can use mutt or vi to view the message
directly.  (I told exim to include the mbox From_ line at the
beginning of each message, so in effect I have lots of mbox folders
containing one message each in the maildir folder :-))  In addition,
it is easy to limit your grep to just new messages or old messages as
well by choosing to grep through only the 'new' or 'cur' subdirectory.

-D

-- 
Trust in the Lord with all your heart and lean not on your own
understanding; in all your ways acknowledge Him, and He will make your
paths straight.
Proverbs 3:5-6
 
http://dman.ddts.net/~dman/



msg29801/pgp0.pgp
Description: PGP signature


Re: Locking strategies and MAILPATH

2002-07-22 Thread Vincent Lefevre

On Mon, Jul 22, 2002 at 08:58:42 -0500, Derrick 'dman' Hudson wrote:
 On Mon, Jul 22, 2002 at 09:39:52AM +0200, Vincent Lefevre wrote:
 | I prefer to keep the mbox format for these mailboxes, because this
 | makes easier for other operations (like grepping or copying them).
 
 grep -r
 cp -r
 
 How does maildir inhibit those operations?

I haven't said that they were inhibited, I have said that using the
mbox format makes things easier. Sometimes, I need an interactive cp.
And how can cp -r (or scp -r) remove files from the destination
mailbox? Indeed, I sometimes delete messages from mailboxes.

 I actually find maildir better for grepping because grep tells me
 which file (message) the match was found in.

This is true, but in general, I'm interested in several messages
(e.g. a thread). When I've found the mailbox containing the files
I was searching for, I can use Mutt and the limit function.

 Then I can use mutt or vi to view the message directly. (I told exim
 to include the mbox From_ line at the beginning of each message, so
 in effect I have lots of mbox folders containing one message each in
 the maildir folder :-)) In addition, it is easy to limit your grep
 to just new messages or old messages as well by choosing to grep
 through only the 'new' or 'cur' subdirectory.

In my case, all the messages are read.

-- 
Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA



Re: Locking strategies and MAILPATH

2002-07-22 Thread David T-G

Vincent --

...and then Vincent Lefevre said...
% 
% On Mon, Jul 22, 2002 at 10:00:09 -0500, David T-G wrote:
%  
%  ...and then Vincent Lefevre said...
%  % 
%  % It seems that to force the dotlock locking strategy, one needs to use
%  % the --with-homespool option. But then, mutt -v says:
%  
%  That doesn't make sense; I've had dotlocking with my mail spool under
%  /var before.  In fact, the whole reason for having a separate dotlock
%  program with its own priv permissions is specifically because of mail
%  spools under /var instead of $HOME.
% 
% I wasn't talking of a separate dotlock program. I just wanted Mutt
% to use the dotlock mechanism (preferably the internal one).

You'd *prefer* the internal?  OK.


% 
%  % MAILPATH=mailbox
%  % 
%  % Here, mailbox doesn't correspond to anything. So, is it a problem?
%  
%  What if you compile with HOMESPOOL turned off?
% 
% With --with-homespool:
% +USE_DOTLOCK
% MAILPATH=mailbox
% 
% Without --with-homespool:
% -USE_DOTLOCK
% MAILPATH=

Hmmm...  I see what you mean; there's not --use-dotlock switch.  Well,
you could

  --enable-external-dotlock

to force it, even though you'd then have the external program.  [Why
don't you like that, though?]

Come to think of it, I think dotlocking is the default, so if you
specifically disable fcntl (and perhaps flock) then you'll get that.
When you install, check the perms on the binary; if you don't have the
external program, then you'll probably have an sgid mutt, which can then
do dotlocking in /var -- and which, with or without the perms, can lock
in your home dir.


% 
%  % Note that my only spool mailbox is an IMAP mailbox. But I need a locking
%  % strategy for the postpone and archive mailboxes (under NFS). As fcntl is
%  % not reliable here, I think I'll disable it and use dotlocking only.
%  
%  Sounds good.
% 
% Well, the lock manager has just been cleaned here, so fcntl is now OK
% (for the moment).

That's good :-)


HTH  HAND

:-D
-- 
David T-G  * It's easier to fight for one's principles
(play) [EMAIL PROTECTED] * than to live up to them. -- fortune cookie
(work) [EMAIL PROTECTED]
http://www.justpickone.org/davidtg/Shpx gur Pbzzhavpngvbaf Qrprapl Npg!




msg29805/pgp0.pgp
Description: PGP signature


Re: Locking strategies and MAILPATH

2002-07-22 Thread David T-G

Vincent --

...and then Vincent Lefevre said...
% 
% It seems that to force the dotlock locking strategy, one needs to use
% the --with-homespool option. But then, mutt -v says:

That doesn't make sense; I've had dotlocking with my mail spool under
/var before.  In fact, the whole reason for having a separate dotlock
program with its own priv permissions is specifically because of mail
spools under /var instead of $HOME.


% 
% MAILPATH=mailbox
% 
% Here, mailbox doesn't correspond to anything. So, is it a problem?

What if you compile with HOMESPOOL turned off?


% 
% Note that my only spool mailbox is an IMAP mailbox. But I need a locking
% strategy for the postpone and archive mailboxes (under NFS). As fcntl is
% not reliable here, I think I'll disable it and use dotlocking only.

Sounds good.


% 
% -- 
% Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ - 100%
% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
% des Jeux Mathématiques et Logiques, TETRHEX, etc.
% Work: CR INRIA - computer arithmetic / SPACES project at LORIA


HTH  HAND

:-D
-- 
David T-G  * It's easier to fight for one's principles
(play) [EMAIL PROTECTED] * than to live up to them. -- fortune cookie
(work) [EMAIL PROTECTED]
http://www.justpickone.org/davidtg/Shpx gur Pbzzhavpngvbaf Qrprapl Npg!




msg29806/pgp0.pgp
Description: PGP signature


Re: Locking strategies and MAILPATH

2002-07-22 Thread Vincent Lefevre

On Mon, Jul 22, 2002 at 10:25:08 -0500, David T-G wrote:
 Hmmm...  I see what you mean; there's not --use-dotlock switch.  Well,
 you could
 
   --enable-external-dotlock
 
 to force it, even though you'd then have the external program.  [Why
 don't you like that, though?]

An additional --use-dotlock switch would be better. Anyway, I've
just tried with --enable-external-dotlock and it has no effect:
-USE_DOTLOCK.

 Come to think of it, I think dotlocking is the default, so if you
 specifically disable fcntl (and perhaps flock) then you'll get that.

Here, dotlocking is disabled by default.

 When you install, check the perms on the binary; if you don't have the
 external program, then you'll probably have an sgid mutt, which can then
 do dotlocking in /var -- and which, with or without the perms, can lock
 in your home dir.

I only need to lock things in my home dir (the spool mailbox in
/var/... no longer exists).

-- 
Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA



Re: Locking strategies and MAILPATH

2002-07-22 Thread Vincent Lefevre

On Mon, Jul 22, 2002 at 10:00:09 -0500, David T-G wrote:
 Vincent --
 
 ...and then Vincent Lefevre said...
 % 
 % It seems that to force the dotlock locking strategy, one needs to use
 % the --with-homespool option. But then, mutt -v says:
 
 That doesn't make sense; I've had dotlocking with my mail spool under
 /var before.  In fact, the whole reason for having a separate dotlock
 program with its own priv permissions is specifically because of mail
 spools under /var instead of $HOME.

I wasn't talking of a separate dotlock program. I just wanted Mutt
to use the dotlock mechanism (preferably the internal one).

 % MAILPATH=mailbox
 % 
 % Here, mailbox doesn't correspond to anything. So, is it a problem?
 
 What if you compile with HOMESPOOL turned off?

With --with-homespool:
+USE_DOTLOCK
MAILPATH=mailbox

Without --with-homespool:
-USE_DOTLOCK
MAILPATH=

 % Note that my only spool mailbox is an IMAP mailbox. But I need a locking
 % strategy for the postpone and archive mailboxes (under NFS). As fcntl is
 % not reliable here, I think I'll disable it and use dotlocking only.
 
 Sounds good.

Well, the lock manager has just been cleaned here, so fcntl is now OK
(for the moment).

-- 
Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA



Re: Locking strategies and MAILPATH

2002-07-22 Thread Derrick 'dman' Hudson

On Mon, Jul 22, 2002 at 04:21:24PM +0200, Vincent Lefevre wrote:
| On Mon, Jul 22, 2002 at 08:58:42 -0500, Derrick 'dman' Hudson wrote:
|  On Mon, Jul 22, 2002 at 09:39:52AM +0200, Vincent Lefevre wrote:
|  | I prefer to keep the mbox format for these mailboxes, because this
|  | makes easier for other operations (like grepping or copying them).
|  
|  grep -r
|  cp -r
|  
|  How does maildir inhibit those operations?
| 
| I haven't said that they were inhibited, I have said that using the
| mbox format makes things easier. Sometimes, I need an interactive cp.

Interactive cp?  Is that like using debugfs to copy inodes manually?
(yes, that's joke, but I really don't know what can be interactive
about cp)

| And how can cp -r (or scp -r) remove files from the destination
| mailbox?

*Those* commands don't, the 'rm' command does :-).

| Indeed, I sometimes delete messages from mailboxes.

Is this always one-sided?  Or can you received/delete messages from
either side and then want to sync them?

If it is the former you can fairly easily script it with varying
amounts of efficiency.  For example, just 'rm -rf' the folder on the
destination and 'scp -r' to update it.

In the latter case you need a program that understands mail folders
(regardless of whether you use mbox or maildir) to properly sync the
two folders.

Perhaps a better solution is to use imap and have just one folder
store.  (*perhaps*)

|  I actually find maildir better for grepping because grep tells me
|  which file (message) the match was found in.
| 
| This is true, but in general, I'm interested in several messages
| (e.g. a thread). When I've found the mailbox containing the files
| I was searching for, I can use Mutt and the limit function.

Can the limit function operate on message bodies?  From what I've seen
it seems to operate on the subject only (or certain other headers and
properties if you use the right tilde magic).

HTH,
-D

-- 
A)bort, R)etry, D)o it right this time
 
http://dman.ddts.net/~dman/



msg29819/pgp0.pgp
Description: PGP signature