Bug#622677: tmux segfaults with [lost server] if second pane is closed after third pane has been broke out
This should fix it I think:
Index: cmd-break-pane.c
===
RCS file: /cvs/src/usr.bin/tmux/cmd-break-pane.c,v
retrieving revision 1.10
diff -u -p -r1.10 cmd-break-pane.c
--- cmd-break-pane.c4 Jan 2011 00:42:46 - 1.10
+++ cmd-break-pane.c8 May 2011 21:26:32 -
@@ -57,12 +57,18 @@ cmd_break_pane_exec(struct cmd *self, st
return (-1);
}
- TAILQ_REMOVE(wl-window-panes, wp, entry);
- if (wl-window-active == wp) {
- wl-window-active = TAILQ_PREV(wp, window_panes, entry);
- if (wl-window-active == NULL)
- wl-window-active = TAILQ_NEXT(wp, entry);
- }
+ w = wl-window;
+ TAILQ_REMOVE(w-panes, wp, entry);
+ if (wp == w-active) {
+ w-active = w-last;
+ w-last = NULL;
+ if (w-active == NULL) {
+ w-active = TAILQ_PREV(wp, window_panes, entry);
+ if (w-active == NULL)
+ w-active = TAILQ_NEXT(wp, entry);
+ }
+ } else if (wp == w-last)
+ w-last = NULL;
layout_close_pane(wp);
w = wp-window = window_create1(s-sx, s-sy);
On Sat, Apr 23, 2011 at 10:44:38PM +0100, Nicholas Marriott wrote:
I can reproduce this, looks like bad cursor positioning after
break-pane. Mailing so others can look and it doesn't get forgotten.
--
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
___
tmux-users mailing list
tmux-us...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tmux-users
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622677: tmux segfaults with [lost server] if second pane is closed after third pane has been broke out
I can reproduce this, looks like bad cursor positioning after break-pane. Mailing so others can look and it doesn't get forgotten. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620304: tmux: Incorrect dropping of privileges allows users to obtain utmp group privileges
Thanks, I'm glad to hear you are reconsidering this. I might put it in the tmux FAQ as well. On Wed, Apr 13, 2011 at 09:51:00AM +0200, Karl Ferdinand Ebert wrote: Hello Nicholas, On Wed, Apr 13, 2011 at 12:31 AM, Nicholas Marriott [1]nicholas.marri...@gmail.com wrote: Hi Not to say I told you so or anything, but this might be a good time to reiterate that doing this is a bad idea: the minor inconvenience it prevents (easily avoided by the user with either tmux -S or by setting TMPDIR) is much less of a potential problem than running with elevated privileges. Romain and I are about to change the behaviour and drop the privileges completely. Maybe at the end it will be only setting a proper TMPDIR or having a note for the users to point out to how to use 'tmux -S'. I should have considered this in the first place. Now I'm going to have to spend at least some of my time saying no, not tmux, Debian security problem... As this is my fault for having introduced the modifcations I apologize deeply for wasting your time. For the record Ubuntu is affected too but not Fedora which has a seperate group 'tmux'. Best regards, Ferdinand References Visible links 1. mailto:nicholas.marri...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620304: tmux: Incorrect dropping of privileges allows users to obtain utmp group privileges
Hi Not to say I told you so or anything, but this might be a good time to reiterate that doing this is a bad idea: the minor inconvenience it prevents (easily avoided by the user with either tmux -S or by setting TMPDIR) is much less of a potential problem than running with elevated privileges. Now I'm going to have to spend at least some of my time saying no, not tmux, Debian security problem... Nicholas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550701: tmux does not support screen-256color like it claims
On Sat, Oct 24, 2009 at 03:54:57PM -0400, Thomas Dickey wrote: On Sat, Oct 24, 2009 at 07:20:28PM +0200, Nicholas Marriott wrote: On Sat, Oct 24, 2009 at 12:49:31AM +1100, Tim Allen wrote: On Fri, Oct 23, 2009 at 01:24:00PM +0100, Nicholas Marriott wrote: It appears screen-256color converts colours 8-15 into 90-97 which are an extension designed to allow bright colours without the bold attribute (bold font). Looking at xterm's ctlseqs.pdf, it refers to these 90-97 and 100-107 codes as aixterm codes; I suppose before xterm invented the 88- and 256-color hack, IBM had their own ideas about how to extend ECMA48 beyond 8 colours. Yes, I know, but the question is why does terminfo bother itself converting 8-15 to 90-97 when it could just pass it through and get the same result since 90-97 are the same as 8-15 in the 256-colour palette. setaf/setab used to use the standard ANSI SGR sequence in xterm- and screen-256color, the change to use the 256-colour extension is relatively recent. as noted in terminfo.src # 2006-06-24 ... # * improve xterm-256color by combining the ibm+16color setaf/setab # strings with SGR 48. The setf/setb strings also are cancelled here # rather than omitted so derived entries will cancel those also -Alain # Bench The improvement reduces the number of characters sent. Ah yes, of course, I missed that. Colors 8-15 use the aixterm SGR (which isn't ANSI SGR). Right. Since aixterm 16-colors are part of the default configuration settings, it's reasonable to count on the controls being present. I can't count on them being present because tmux may be detached from a terminal which supports them and reattached to a terminal which does not, so unless I can establish for sure from terminfo that they are I have to assume they are not supported and convert them to bold+setaf/setab 0-7. With latest terminfo I could say that any terminal with colors=256 has a setaf/setab that correctly accepts all 256 colours, then use setaf/setab instead of sending \\033[38;5;c directly to get the benefit of any optimisations in terminfo, but that isn't a safe assumption with an older terminfo.src :-/. I suppose I could send the aixterm codes myself on 256 colour terminals but I'm not quite sure it is worth the effort. Plus 256 colours, default colours and mouse on/off are the only things for which tmux bypasses terminfo and I'd rather not add more. Actually I should use op to drop sending 39,49 directly as well. Actually, in the copy with ncurses 5.7, xterm-256color and screen-256color both have the same setaf/setab caps (inherited from xterm+256color). Debian must be on an older revision or have a local change. older... -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550701: tmux does not support screen-256color like it claims
On Sat, Oct 24, 2009 at 07:42:26PM -0400, Thomas Dickey wrote: On Sat, Oct 24, 2009 at 10:11:30PM +0100, Nicholas Marriott wrote: On Sat, Oct 24, 2009 at 03:54:57PM -0400, Thomas Dickey wrote: Since aixterm 16-colors are part of the default configuration settings, it's reasonable to count on the controls being present. I can't count on them being present because tmux may be detached from a terminal which supports them and reattached to a terminal which does not, so unless I can establish for sure from terminfo that they are I have to assume they are not supported and convert them to bold+setaf/setab 0-7. well... if you're using terminfo to tell the number of colors (256 for example), it's a reasonably safe assumption that xterm supports both the aixterm (16-color) and 256-color controls. Unless of course the $TERM is set incorrectly, in which case the 256-colors is suspect. For other terminals, the 16-color feature was used - which accounts for the 16color variants. Yes, I can make that assumption but I'd have to bypass terminfo and output the 9x and 10x codes directly and I'm reluctant to add another case where I do that. I suppose it wouldn't do any harm, maybe I'll give it a go. With latest terminfo I could say that any terminal with colors=256 has a setaf/setab that correctly accepts all 256 colours, then use setaf/setab instead of sending \\033[38;5;c directly to get the benefit of any optimisations in terminfo, but that isn't a safe assumption with an older terminfo.src :-/. I'm not sure why - from what I'm reading the only problem was that tmux didn't recognize the aixterm codes. Yes, that problem is fixed, but I was thinking it would be nice to get the optimisation automatically using setaf/setab. Unfortunately, until very recently OpenBSD did this: $ TERM=xterm-256color tput setaf 10|cat -v; echo ^[[310m I thought it was fixed by using a newer terminfo.src (sorry) but checking again it is actually fixed by a separate OpenBSD bug fix just a few weeks ago. Anyway because of this tmux bypasses terminfo and just sends \\033[38;5;c directly and I am stuck with that at least until my fix gets into a couple of releases (or I #ifdef __OpenBSD__ it in tmux). On that note (I was actually going to mail you separately about this), there is a minor comment fix in OpenBSD that it would be nice if you could apply to your terminfo.src to make one fewer local change, a diff below. Thanks --- terminfo.src.orig Sun Oct 25 01:11:52 2009 +++ terminfo.srcSun Oct 25 01:13:22 2009 @@ -19562,7 +19562,7 @@ # # CTRM terminal emulator -# 1. underlining is not allowed with colors: first, is is simulated by +# 1. underlining is not allowed with colors: first, it is simulated by # black on white, second, it disables background color manipulations. # 2. BLINKING, REVERSE and BOLD are allowed with colors, # so we have to save their status in the static registers A, B and H -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550701: tmux does not support screen-256color like it claims
Hi If you set TERM to anything aside from screen or screen-256color inside tmux you will get screen corruption because applications will send the incorrect escape sequences. This is not a bug. The FAQ does not say that setting TERM to screen-256color will just work, although it could probably be clearer. You need to do two things: 1) Set TERM=screen-256color inside so that applications INSIDE tmux know that it supports 256 colours, you can do this however you like but default-terminal is usually easiest. 2) Ensure that tmux knows the outside terminal support 256 colours, either by setting TERM to something with colors=256, or matching *256col*, or by passing -2 to tmux. If you do not do this, tmux will translate ALL colours in the 256 colour palette into their nearest eight-colour equivalent. If you do step (2) and can successfully see 256 colours with, for example, the colortest script at http://www.vim.org/scripts/script.php?script_id=1349, and get them by using TERM=xterm-256color, then it sounds like a problem with the screen-256color terminfo entry. In this case, please send me a copy of infocmp screen-256color and tmux info. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550701: tmux does not support screen-256color like it claims
Hi
Okay, I can see the problem.
$ TERM=screen-256color tput setaf 15|cat -v
^[[97m
$ TERM=xterm-256color tput setaf 15|cat -v
^[[38;5;15
It appears screen-256color converts colours 8-15 into 90-97 which are an
extension designed to allow bright colours without the bold attribute (bold
font).
Looking briefly at xterm-256color in terminfo.src I can't see why it doesn't do
the same but I don't have time or inclination to dig into it right now.
I'm not certain why it does this because in 256 colour mode, colours 8-15 are
supposed to be the bright ANSI colours anyway, compare:
$ echo -e \\033[93mabc\\033[38\;5\;11mdef\\033[33m\\033[1mxyz
This appears to be yet another terminal capability without a terminfo flag
allowing it to be detected so tmux can't make use of it explicitly (ie pass it
through if it is supported). However, converting it into colours 8-15 (which
should then be converted into 3x+bold for non-256-colour terminals) should
hopefully do the trick.
Please try this:
Index: input.c
===
RCS file: /cvsroot/tmux/tmux/input.c,v
retrieving revision 1.97
diff -u -p -r1.97 input.c
--- input.c 15 Oct 2009 01:53:48 - 1.97
+++ input.c 23 Oct 2009 12:17:55 -
@@ -1494,6 +1494,28 @@ input_handle_sequence_sgr(struct input_c
gc-flags = ~GRID_FLAG_BG256;
gc-bg = 8;
break;
+ case 90:
+ case 91:
+ case 92:
+ case 93:
+ case 94:
+ case 95:
+ case 96:
+ case 97:
+ gc-flags |= GRID_FLAG_FG256;
+ gc-fg = m - 82;
+ break;
+ case 100:
+ case 101:
+ case 102:
+ case 103:
+ case 104:
+ case 105:
+ case 106:
+ case 107:
+ gc-flags |= GRID_FLAG_BG256;
+ gc-bg = m - 92;
+ break;
}
}
}
On Fri, Oct 23, 2009 at 10:30:34PM +1100, Tim Allen wrote:
On Fri, Oct 23, 2009 at 11:11:18AM +0100, Nicholas Marriott wrote:
The FAQ does not say that setting TERM to screen-256color will just
work, although it could probably be clearer. You need to do two
things:
My apologies - I already have 256-color support with appropriate TERM
settings working in gnome-terminal and screen, so from my point of view,
setting TERM inside tmux was the only thing I believed missing.
If you do step (2) and can successfully see 256 colours with, for
example, the colortest script at
http://www.vim.org/scripts/script.php?script_id=1349, and get them by
using TERM=xterm-256color, then it sounds like a problem with the
screen-256color terminfo entry. In this case, please send me a copy of
infocmp screen-256color and tmux info.
I have attached the output of infocmp screen-256color and tmux info
as you requested.
The colortest script that you link to is useful but verbose - I have
written my own color-test script (also attached) whose output is more
compact, and also attached a screenshot comparing the output with
TERM=screen-256color versus the output with TERM=xterm-256color. It
seems that the 256 colours are represented well enough, it's the colours
from 8-15 that aren't being interpreted correctly.
# Reconstructed via infocmp from file: /lib/terminfo/s/screen-256color
screen-256color|GNU Screen with 256 colors,
am, km, mir, msgr, xenl,
colors#256, cols#80, it#8, lines#24, ncv#3, pairs#32767,
acsc=++\,\,--..00``aaffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
bel=^G, blink=\E[5m, bold=\E[1m, cbt=\E[Z, civis=\E[?25l,
clear=\E[H\E[J, cnorm=\E[34h\E[?25h, cr=^M,
csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
cud=\E[%p1%dB, cud1=^J, cuf=\E[%p1%dC, cuf1=\E[C,
cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\EM,
cvvis=\E[34l, dch=\E[%p1%dP, dch1=\E[P, dl=\E[%p1%dM,
dl1=\E[M, ed=\E[J, el=\E[K, el1=\E[1K, enacs=\E(B\E)0,
flash=\Eg, home=\E[H, ht=^I, hts=\EH, ich=\E[%p1%d@,
il=\E[%p1%dL, il1=\E[L, ind=^J, initc@, is2=\E)0, kbs=^H,
kcbt=\E[Z, kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA,
kdch1=\E[3~, kend=\E[4~, kf1=\EOP, kf10=\E[21~,
kf11=\E[23~, kf12=\E[24~, kf2=\EOQ, kf3=\EOR, kf4=\EOS,
kf5=\E[15~, kf6=\E[17~, kf7=\E[18~, kf8=\E[19~, kf9=\E[20~,
khome=\E[1~, kich1=\E[2~, kmous=\E[M, knp=\E[6~, kpp=\E[5~,
nel=\EE, op=\E[39;49m, rc=\E8, rev=\E[7m, ri=\EM, rmacs=^O,
rmcup=\E[?1049l, rmir=\E[4l, rmkx=\E[?1l\E, rmso=\E[23m,
rmul=\E[24m, rs2=\Ec\E[?1000l\E[?25h, sc=\E7,
setab=\E[%?%p1%{8}%%t4%p1%d%e%p1%{16}%%t10%p1%{8}%-%d%e48;5;%p1%d%;m,
setaf=\E[%?%p1%{8}%%t3%p1%d%e%p1%{16}%%t9%p1%{8}%-%d%e38;5;%p1%d%;m,
sgr=\E[0%?%p6%t;1%;%?%p1%t;3
Bug#550701: tmux does not support screen-256color like it claims
On Sat, Oct 24, 2009 at 12:49:31AM +1100, Tim Allen wrote: On Fri, Oct 23, 2009 at 01:24:00PM +0100, Nicholas Marriott wrote: It appears screen-256color converts colours 8-15 into 90-97 which are an extension designed to allow bright colours without the bold attribute (bold font). Looking at xterm's ctlseqs.pdf, it refers to these 90-97 and 100-107 codes as aixterm codes; I suppose before xterm invented the 88- and 256-color hack, IBM had their own ideas about how to extend ECMA48 beyond 8 colours. Yes, I know, but the question is why does terminfo bother itself converting 8-15 to 90-97 when it could just pass it through and get the same result since 90-97 are the same as 8-15 in the 256-colour palette. setaf/setab used to use the standard ANSI SGR sequence in xterm- and screen-256color, the change to use the 256-colour extension is relatively recent. Looking briefly at xterm-256color in terminfo.src I can't see why it doesn't do the same but I don't have time or inclination to dig into it right now. There's a family of screen terminfo entries, and a family of xterm terminfo entries; if screen-256color inherits from screen-16color but xterm-256color overrides setab and setaf entirely, that might explain it. I'm not sure how to go about checking that, though, and as you say, Actually, in the copy with ncurses 5.7, xterm-256color and screen-256color both have the same setaf/setab caps (inherited from xterm+256color). Debian must be on an older revision or have a local change. This appears to be yet another terminal capability without a terminfo flag allowing it to be detected so tmux can't make use of it explicitly (ie pass it through if it is supported). However, converting it into colours 8-15 (which should then be converted into 3x+bold for non-256-colour terminals) should hopefully do the trick. I applied your patch to the Debian source, rebuilt the package and installed it, and my color-test script works fine now as does my mutt configuration. Thank you very much! Okay cool, I will commit it. Thanks for the report. Regards Nicholas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#538194: fdm doesn't handle EXDEV when linking files.
This is committed to CVS HEAD now and will be in the next release of fdm when I get around to it. Thanks! On Sat, Jul 25, 2009 at 08:02:46PM +0200, opter_l wrote: As discussed here and on IRC. I have replaced the link() call in deliver-maildir.c by a call to a new `safemove()' function. This function move a file with link() + unlink() or if it fails on EXDEV by using rename(). The patch is joined with this mail. I have tested it on AFS and ext3; the regressions test suite successfully passed on OpenBSD 4.5. Nicholas, I let you write the bits in the user manual about using fdm with this patch on AFS. I believe that it will be more clear if you do it. Thanks a lot for your help about this. I am open to any suggestion. -- Louis Opter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#538194: fdm doesn't handle EXDEV when linking files.
I'm going to run with this for a few days and if I don't see any problems I'll commit it, then it'll be in 1.7 when I get around to doing some more stuff on fdm. Thanks On Sat, Jul 25, 2009 at 08:02:46PM +0200, opter_l wrote: As discussed here and on IRC. I have replaced the link() call in deliver-maildir.c by a call to a new `safemove()' function. This function move a file with link() + unlink() or if it fails on EXDEV by using rename(). The patch is joined with this mail. I have tested it on AFS and ext3; the regressions test suite successfully passed on OpenBSD 4.5. Nicholas, I let you write the bits in the user manual about using fdm with this patch on AFS. I believe that it will be more clear if you do it. Thanks a lot for your help about this. I am open to any suggestion. -- Louis Opter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#538194: fdm doesn't handle EXDEV when linking files.
Sorry for the delay, I was a bit busy yesterday. This looks great to me, I will give it further test, add the manual bits and commit it later on today or tomorrow. Thanks for your work! On Sat, Jul 25, 2009 at 08:02:46PM +0200, opter_l wrote: As discussed here and on IRC. I have replaced the link() call in deliver-maildir.c by a call to a new `safemove()' function. This function move a file with link() + unlink() or if it fails on EXDEV by using rename(). The patch is joined with this mail. I have tested it on AFS and ext3; the regressions test suite successfully passed on OpenBSD 4.5. Nicholas, I let you write the bits in the user manual about using fdm with this patch on AFS. I believe that it will be more clear if you do it. Thanks a lot for your help about this. I am open to any suggestion. -- Louis Opter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#538194: fdm doesn't handle EXDEV when linking files.
Hi Saying that, I don't see a reason not to make this work for people who are prepared to accept the risk or who know for sure they are delivering mail sequentially. With fdm, you will want to set queue-high/queue-low to 1, and perhaps parallel-accounts to 1 if you have multiple accounts delivering to the same maildir. You mean because of locks in the file system code with rename ? I meant there is a possibility of having races between fdm delivery children (it forks a separate one for each child), although I had another look and since the filename contains the PID that is more unlikely than I first thought - most platforms don't reuse PIDs that quickly. It is still unpredictable so do note that if 1 process is accessing the maildir at a time, you could lose mail, even if it is an outside chance. I had not thought of. But, the read on a maildir -with a big amount of mails- stays faster, isn't it ? (Actually, I am new to fdm/maildir/mboxes/mutt... I used Evolution and webmails...) It depends how it is implemented but there is no reason mbox reads or appends should be slower than maildir; a full mailbox scan will be slower and deletion will be much slower. The biggest problems with mboxes is that only one process can access them simultaneously and some big operations (like delete) can require a copy and rewrite of the entire file to do safely. I really don't like mboxes, I just wanted to note that they do have locking so you will not lose mail due to this limitation in AFS. That doesn't excuse their other problems though. Thinking about it again if I was you I would probably use maildirs anyway (once fdm is changed to work around the problem) but you should try to be careful that as much as possible only one program writes to the maildir at a time. This diff is reasonable, but if possible I'd rather it was implemented as a wrapper function (xlink?) which has the same semantics as link but falls back to stat/rename if it fails with EXDEV. Okay, I will try to study it, tomorrow. Great! Thanks Nicholas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#538194: fdm doesn't handle EXDEV when linking files.
Hi
Thanks for the report.
This isn't really an fdm bug per se, the point of maildirs is to allow delivery
to happen safely without locking. On AFS you are probably best using mboxes
which have flaws but can be locked atomically.
Saying that, I don't see a reason not to make this work for people who are
prepared to accept the risk or who know for sure they are delivering mail
sequentially. With fdm, you will want to set queue-high/queue-low to 1, and
perhaps parallel-accounts to 1 if you have multiple accounts delivering to the
same maildir.
This diff is reasonable, but if possible I'd rather it was implemented as a
wrapper function (xlink?) which has the same semantics as link but falls back
to stat/rename if it fails with EXDEV.
It will also probably need a note in the manual documenting this behaviour.
Offhand I don't think there are any other places where fdm does a
cross-directory link.
Regards
Nicholas
On Thu, Jul 23, 2009 at 11:50:37PM +0200, Frank Terbeck wrote:
[ Ccing the fdm-users mailing list. Please reply to all addresses in ]
[ To: and Cc: in order to keep all involved parties and the debian ]
[ BTS in the loop. ]
A new bug report via the debian BTS, which includes a suggestion for a
fix.
The referenced bug #352589 can be found here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=352589
Regards, Frank
Louis Opter opte...@epitech.net:
Package: fdm
Version: 1.5-3
Severity: important
Tags: patch
Dear maintainer,
link() fails with EXDEV when you try to link files accross file systems.
On the AFS file system, this also occurs between directories :
http://docs.openafs.org/AdminGuide/ch02.html#HDRWQ32
This special case breaks fdm when using maildirs on OpenAFS.
I suggest a patch which workaround EXDEV by using stat() and rename().
I haven't run fdm's regressions tests on it. I have just checked it on
AFS and ext3.
A similar issue has been fixed in openssh (see #352589).
The same bug certainly exists in other parts of fdm.
Here is the code :
--- fdm-1.5.orig/deliver-maildir.c2008-03-06 10:25:32.0 +0100
+++ fdm-1.5-3.debian.louis/deliver-maildir.c 2009-07-23 21:28:34.418851829
+0200
@@ -146,6 +146,7 @@
char src[MAXPATHLEN], dst[MAXPATHLEN];
int fd;
ssize_t n;
+ struct stat sb;
name = NULL;
fd = -1;
@@ -195,28 +196,52 @@
fd = -1;
/*
- * Create the new path and attempt to link it. A failed link jumps
- * back to find another name in the tmp directory.
+ * Create the new path and attempt to link it. A failed link on EEXIST
+ * jumps back to find another name in the tmp directory.
*/
if (ppath(dst, sizeof dst, %s/new/%s, path, name) != 0)
goto error_unlink;
log_debug2(
%s: linking .../tmp/%s to .../new/%s, a-name, name, name);
if (link(src, dst) != 0) {
- if (errno == EEXIST) {
- log_debug2(%s: %s: link failed, a-name, src);
+ log_debug2(%s: %s: link failed, a-name, src);
+ /*
+ * EXDEV must also be handled, especially for the AFS filesystem
+ * where hardlinks can't traverse directories :
+ * http://docs.openafs.org/AdminGuide/ch02.html#HDRWQ32
+ */
+ if (errno == EXDEV) {
+ log_debug2(%s: renaming .../tmp/%s to .../new/%s,
+ a-name, name, name);
+ /*
+ * But stat + rename can be racy.
+ */
+ if (stat(dst, sb) == -1) {
+ if (errno != ENOENT || rename(src, dst) != 0) {
+ log_debug2(%s: %s: rename failed,
+ a-name, src);
+ goto error_cleanup;
+ }
+ } else { /* EEXIST */
+ if (unlink(src) != 0)
+ fatal(unlink failed);
+ cleanup_deregister(src);
+ goto restart;
+ }
+ } else if (errno == EEXIST) {
if (unlink(src) != 0)
fatal(unlink failed);
cleanup_deregister(src);
goto restart;
- }
- goto error_unlink;
+ } else /* Dot it only if we are not on EXDEV */
+ goto error_unlink;
+ } else {
+ /* Unlink the original tmp file. */
+ log_debug2(%s: unlinking .../tmp/%s, a-name, name);
+ if (unlink(src) != 0)
+
Bug#528818: fdm log for debian bug 528818
Okay, I have committed some parts of the diff and made a couple of other tweaks
which were sometimes causing it to hang. Please test the diff below instead.
Index: fdm.c
===
RCS file: /cvsroot/fdm/fdm/fdm.c,v
retrieving revision 1.183
diff -u -p -r1.183 fdm.c
--- fdm.c 25 May 2009 21:47:23 - 1.183
+++ fdm.c 26 May 2009 06:08:03 -
@@ -44,9 +44,11 @@ const char *malloc_options = AFGJPRX;
voidsighandler(int);
struct child *check_children(struct children *, u_int *);
+int wait_children(struct children *, struct children *);
struct conf conf;
+volatile sig_atomic_t sigchld;
volatile sig_atomic_t sigusr1;
volatile sig_atomic_t sigint;
volatile sig_atomic_t sigterm;
@@ -67,6 +69,9 @@ sighandler(int sig)
case SIGTERM:
sigterm = 1;
break;
+ case SIGCHLD:
+ sigchld = 1;
+ break;
}
}
@@ -181,6 +186,79 @@ check_children(struct children *children
return (NULL);
}
+/* Wait for a child and deal with its exit. */
+int
+wait_children(struct children *children, struct children *dead_children)
+{
+ struct child*child, *child2;
+ pid_tpid;
+ int status, retcode = 0;
+ u_inti, j;
+
+ for (;;) {
+ log_debug3(parent: waiting for children);
+ /* Wait for a child. */
+ switch (pid = waitpid(WAIT_ANY, status, WNOHANG)) {
+ case 0:
+ return (0);
+ case -1:
+ if (errno == ECHILD)
+ return (0);
+ fatal(waitpid failed);
+ }
+
+ /* Handle the exit status. */
+ if (WIFSIGNALED(status)) {
+ retcode = 1;
+ log_debug2(parent: child %ld got signal %d,
+ (long) pid, WTERMSIG(status));
+ } else if (!WIFEXITED(status)) {
+ retcode = 1;
+ log_debug2(parent: child %ld exited badly,
+ (long) pid);
+ } else {
+ if (WEXITSTATUS(status) != 0)
+ retcode = 1;
+ log_debug2(parent: child %ld returned %d,
+ (long) pid, WEXITSTATUS(status));
+ }
+
+ /* Find this child. */
+ child = NULL;
+ for (i = 0; i ARRAY_LENGTH(children); i++) {
+ child = ARRAY_ITEM(children, i);
+ if (pid == child-pid)
+ break;
+ }
+ if (i == ARRAY_LENGTH(children)) {
+ log_debug2(parent: unidentified child %ld,
+ (long) pid);
+ continue;
+ }
+
+ if (child-io != NULL) {
+ io_close(child-io);
+ io_free(child-io);
+ child-io = NULL;
+ }
+ ARRAY_REMOVE(children, i);
+ ARRAY_ADD(dead_children, child);
+
+ /* If this child was the parent of any others, kill them too. */
+ for (j = 0; j ARRAY_LENGTH(children); j++) {
+ child2 = ARRAY_ITEM(children, j);
+ if (child2-parent != child)
+ continue;
+
+ log_debug2(parent: child %ld died: killing %ld,
+ (long) child-pid, (long) child2-pid);
+ kill(child2-pid, SIGTERM);
+ }
+ }
+
+ return (retcode);
+}
+
__dead void
usage(void)
{
@@ -198,7 +276,6 @@ main(int argc, char **argv)
enum fdmop op = FDMOP_NONE;
const char *proxy = NULL, *s;
char tmp[BUFSIZ], *ptr, *lock = NULL, *user, *home = NULL;
- long n;
struct utsname un;
struct passwd *pw;
struct stat sb;
@@ -207,8 +284,8 @@ main(int argc, char **argv)
TAILQ_HEAD(, account) actaq; /* active accounts */
pid_tpid;
struct children children, dead_children;
- struct child*child, *child2;
- struct io *rio;
+ struct child*child;
+ struct io *dead_io;
struct iolistiol;
double tim;
struct sigaction act;
@@ -218,6 +295,7 @@ main(int argc, char **argv)
struct strings macros;
struct child_fetch_data *cfd;
struct userdata *ud;
+ sigset_t sigset;
#ifdef DEBUG
struct rule *r;
struct action *t;
@@ -676,21 +754,29 @@
Bug#528818: fdm log for debian bug 528818
On Tue, May 26, 2009 at 07:10:05AM +0100, Nicholas Marriott wrote:
Okay, I have committed some parts of the diff and made a couple of other
tweaks
which were sometimes causing it to hang. Please test the diff below instead.
This is better, please try this:
Index: fdm.c
===
RCS file: /cvsroot/fdm/fdm/fdm.c,v
retrieving revision 1.183
diff -u -p -r1.183 fdm.c
--- fdm.c 25 May 2009 21:47:23 - 1.183
+++ fdm.c 26 May 2009 06:23:30 -
@@ -44,9 +44,12 @@ const char *malloc_options = AFGJPRX;
voidsighandler(int);
struct child *check_children(struct children *, u_int *);
+int wait_children(
+struct children *, struct children *, int);
struct conf conf;
+volatile sig_atomic_t sigchld;
volatile sig_atomic_t sigusr1;
volatile sig_atomic_t sigint;
volatile sig_atomic_t sigterm;
@@ -67,6 +70,9 @@ sighandler(int sig)
case SIGTERM:
sigterm = 1;
break;
+ case SIGCHLD:
+ sigchld = 1;
+ break;
}
}
@@ -181,6 +187,81 @@ check_children(struct children *children
return (NULL);
}
+/* Wait for a child and deal with its exit. */
+int
+wait_children(
+struct children *children, struct children *dead_children, int no_hang)
+{
+ struct child*child, *child2;
+ pid_tpid;
+ int status, flags, retcode = 0;
+ u_inti, j;
+
+ flags = no_hang ? WNOHANG : 0;
+ for (;;) {
+ log_debug3(parent: waiting for children);
+ /* Wait for a child. */
+ switch (pid = waitpid(WAIT_ANY, status, flags)) {
+ case 0:
+ return (0);
+ case -1:
+ if (errno == ECHILD)
+ return (0);
+ fatal(waitpid failed);
+ }
+
+ /* Handle the exit status. */
+ if (WIFSIGNALED(status)) {
+ retcode = 1;
+ log_debug2(parent: child %ld got signal %d,
+ (long) pid, WTERMSIG(status));
+ } else if (!WIFEXITED(status)) {
+ retcode = 1;
+ log_debug2(parent: child %ld exited badly,
+ (long) pid);
+ } else {
+ if (WEXITSTATUS(status) != 0)
+ retcode = 1;
+ log_debug2(parent: child %ld returned %d,
+ (long) pid, WEXITSTATUS(status));
+ }
+
+ /* Find this child. */
+ child = NULL;
+ for (i = 0; i ARRAY_LENGTH(children); i++) {
+ child = ARRAY_ITEM(children, i);
+ if (pid == child-pid)
+ break;
+ }
+ if (i == ARRAY_LENGTH(children)) {
+ log_debug2(parent: unidentified child %ld,
+ (long) pid);
+ continue;
+ }
+
+ if (child-io != NULL) {
+ io_close(child-io);
+ io_free(child-io);
+ child-io = NULL;
+ }
+ ARRAY_REMOVE(children, i);
+ ARRAY_ADD(dead_children, child);
+
+ /* If this child was the parent of any others, kill them too. */
+ for (j = 0; j ARRAY_LENGTH(children); j++) {
+ child2 = ARRAY_ITEM(children, j);
+ if (child2-parent != child)
+ continue;
+
+ log_debug2(parent: child %ld died: killing %ld,
+ (long) child-pid, (long) child2-pid);
+ kill(child2-pid, SIGTERM);
+ }
+ }
+
+ return (retcode);
+}
+
__dead void
usage(void)
{
@@ -198,7 +279,6 @@ main(int argc, char **argv)
enum fdmop op = FDMOP_NONE;
const char *proxy = NULL, *s;
char tmp[BUFSIZ], *ptr, *lock = NULL, *user, *home = NULL;
- long n;
struct utsname un;
struct passwd *pw;
struct stat sb;
@@ -207,8 +287,8 @@ main(int argc, char **argv)
TAILQ_HEAD(, account) actaq; /* active accounts */
pid_tpid;
struct children children, dead_children;
- struct child*child, *child2;
- struct io *rio;
+ struct child*child;
+ struct io *dead_io;
struct iolistiol;
double tim;
struct sigaction act;
@@ -676,21 +756,29 @@ main(int argc, char **argv
Bug#528818: fdm log for debian bug 528818
Okay, this is the problem:
gmail-researchut: spamprobe receive: io: poll: Connection timed out
Your pipe process does not return in the timeout, so fdm aborts the
fetch. Unfortunately this then causes various things which sometimes end up
with fdm not exiting correctly.
fdm's management of child processes isn't always very good, particularly when
an error occurs - sometimes stuff doesn't die in the right order and it ends up
with fatal errors. The whole multiprocess idea is to allow fdm to run lots of
things in parallel and to drop privileges when running as root, but I'm not
sure it is worth it now, I should really simplify it a lot and probably forget
about using it as root.
You can see similar problems with a configuration file such as:
set timeout 2
account 'stdin' stdin
match exec 'sleep 10' returns (0, ) action drop
And then eg echo|fdm - f
This diff makes several changes which hopefully should make it a bit more
robust and correctly handle the various child processes on exit.
Please test.
Index: child-deliver.c
===
RCS file: /cvsroot/fdm/fdm/child-deliver.c,v
retrieving revision 1.21
diff -u -p -r1.21 child-deliver.c
--- child-deliver.c 17 May 2009 19:20:08 - 1.21
+++ child-deliver.c 24 May 2009 14:56:51 -
@@ -61,10 +61,10 @@ child_deliver(struct child *child, struc
if (privsep_send(pio, msg, msgbuf) != 0)
fatalx(privsep_send error);
- if (privsep_recv(pio, msg, NULL) != 0)
- fatalx(privsep_recv error);
- if (msg.type != MSG_EXIT)
- fatalx(unexpected message);
+ do {
+ if (privsep_recv(pio, msg, NULL) != 0)
+ fatalx(privsep_recv error);
+ } while (msg.type != MSG_EXIT);
#ifdef DEBUG
COUNTFDS(a-name);
Index: child-fetch.c
===
RCS file: /cvsroot/fdm/fdm/child-fetch.c,v
retrieving revision 1.72
diff -u -p -r1.72 child-fetch.c
--- child-fetch.c 17 May 2009 18:23:45 - 1.72
+++ child-fetch.c 24 May 2009 14:56:51 -
@@ -127,11 +127,11 @@ child_fetch(struct child *child, struct
log_debug3(%s: sending exit message to parent, a-name);
if (privsep_send(pio, msg, NULL) != 0)
fatalx(privsep_send error);
- log_debug3(%s: waiting for exit message from parent, a-name);
- if (privsep_recv(pio, msg, NULL) != 0)
- fatalx(privsep_recv error);
- if (msg.type != MSG_EXIT)
- fatalx(unexpected message);
+ do {
+ log_debug3(%s: waiting for exit message from parent, a-name);
+ if (privsep_recv(pio, msg, NULL) != 0)
+ fatalx(privsep_recv error);
+ } while (msg.type != MSG_EXIT);
#ifdef DEBUG
COUNTFDS(a-name);
Index: child.c
===
RCS file: /cvsroot/fdm/fdm/child.c,v
retrieving revision 1.147
diff -u -p -r1.147 child.c
--- child.c 17 May 2009 19:20:08 - 1.147
+++ child.c 24 May 2009 14:56:51 -
@@ -18,6 +18,7 @@
#include sys/types.h
#include sys/socket.h
+#include sys/wait.h
#include unistd.h
@@ -35,6 +36,9 @@ child_sighandler(int sig)
case SIGUSR1:
sigusr1 = 1;
break;
+ case SIGCHLD:
+ waitpid(WAIT_ANY, NULL, WNOHANG);
+ break;
case SIGTERM:
cleanup_purge();
_exit(1);
@@ -60,6 +64,7 @@ child_fork(void)
sigaddset(act.sa_mask, SIGUSR1);
sigaddset(act.sa_mask, SIGINT);
sigaddset(act.sa_mask, SIGTERM);
+ sigaddset(act.sa_mask, SIGCHLD);
act.sa_flags = SA_RESTART;
act.sa_handler = SIG_IGN;
@@ -75,6 +80,8 @@ child_fork(void)
fatal(sigaction failed);
if (sigaction(SIGTERM, act, NULL) 0)
fatal(sigaction failed);
+ if (sigaction(SIGCHLD, act, NULL) 0)
+ fatal(sigaction failed);
return (0);
default:
Index: command.c
===
RCS file: /cvsroot/fdm/fdm/command.c,v
retrieving revision 1.54
diff -u -p -r1.54 command.c
--- command.c 17 May 2009 18:23:45 - 1.54
+++ command.c 24 May 2009 14:56:51 -
@@ -132,6 +132,8 @@ cmd_start(const char *s, int flags, cons
fatal(signal failed);
if (signal(SIGUSR2, SIG_DFL) == SIG_ERR)
fatal(signal failed);
+if (signal(SIGCHLD, SIG_DFL) == SIG_ERR)
+ fatal(signal failed);
execl(_PATH_BSHELL, sh, -c, s, (char *) NULL);
fatal(execl failed);
@@ -271,10 +273,14 @@ cmd_poll(struct cmd *cmd, char
Bug#529082: tmux: Bad sockethandling
Actually, I'm wrong, it won't break socket recreation since the subdirectories of /var/run/tmux and the socket themselves still have the correct ownership. The other points are correct, however. So you could drop the utmp privileges completely after creating the directory. On Fri, May 22, 2009 at 07:31:17PM +0100, Nicholas Marriott wrote: Hi This patch does not fix the problem - it doesn't drop the utmp privilege after creating the socket so a user can trivially continue to cause the same issue by using the save-buffer command to create a file in /var/run/tmux. If you do drop the privileges, it will break socket recreation with SIGUSR1 which will appear in 0.9 (and you may need to patch this out of the code or USR1 will kill the server). Of course it is completely up to you, but I recommend you don't do this, you are fixing a minor and easily detected denial-of-service problem by granting unnecessary privileges the abuse of which could potentially be greater. If you do want to do it this way, I suggest that rather than overloading the utmp group you create a new group specifically and only for tmux. Best regards Nicholas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#529082: tmux: Bad sockethandling
Hi This patch does not fix the problem - it doesn't drop the utmp privilege after creating the socket so a user can trivially continue to cause the same issue by using the save-buffer command to create a file in /var/run/tmux. If you do drop the privileges, it will break socket recreation with SIGUSR1 which will appear in 0.9 (and you may need to patch this out of the code or USR1 will kill the server). Of course it is completely up to you, but I recommend you don't do this, you are fixing a minor and easily detected denial-of-service problem by granting unnecessary privileges the abuse of which could potentially be greater. If you do want to do it this way, I suggest that rather than overloading the utmp group you create a new group specifically and only for tmux. Best regards Nicholas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528818: fdm: stale lock file remains present
fdm will only remove the lock file if it exits normally (success or a normal
error), it will not remove it on a fatal error (which means a bug) or on
SIGKILL, and it is never going to since I want to know about these cases and
fix them. Please send me the - log of a session (don't forget to remove
passwords and anything else sensitive) when it is interrupted and leaves behind
a lock file.
On Sat, May 16, 2009 at 01:50:00AM +0530, Ritesh Raj Sarraf wrote:
Package: fdm
Version: 1.6-1
Severity: normal
Hi Frank,
There seems to be a problem with the lock file in fdm.
I currently have fdm configured to fetch emails fromi a pop3 server every
10 minutes, using a cron job.
In .fdm.conf, I'm using the following to ensure that there's only one
instance of fdm running.
# Lock file path.
set lock-file ${base}/lock
Since I run it on a laptop, which I frequently keep
connecting/disconnecting and hibernating, at some point this gets
triggered while fdm is running.
I guess that is when sometime fdm is dying and is leaving a stale lock
file.
This then leads to no further fdm processes running because they
see the lock file and assume that an fdm process is already running.
Thus I end up with receiving no email messages until I realise that fdm
has left a stale lock file. Once I manually remove it, every thing runs
as normal.
IMO fdm should handle such error conditions and remove the lock file
when such circumstances trigger.
Ritesh
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.29-2-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages fdm depends on:
ii adduser 3.110 add and remove users and groups
ii libc62.9-12 GNU C Library: Shared libraries
ii libpcre3 7.8-2+b1Perl 5 Compatible Regular
Expressi
ii libssl0.9.8 0.9.8g-16 SSL shared libraries
ii libtdb1 1.1.3~git20090221-1 Trivial Database - shared library
ii zlib1g 1:1.2.3.3.dfsg-13 compression library - runtime
fdm recommends no packages.
fdm suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528818: fdm: stale lock file remains present
Okay, thanks. Let me know. On Sat, May 16, 2009 at 10:13:44PM +0530, Ritesh Raj Sarraf wrote: On Saturday 16 May 2009 13:51:00 Nicholas Marriott wrote: fdm will only remove the lock file if it exits normally (success or a normal error), it will not remove it on a fatal error (which means a bug) or on SIGKILL, and it is never going to since I want to know about these cases and fix them. Please send me the - log of a session (don't forget to remove passwords and anything else sensitive) when it is interrupted and leaves behind a lock file. I suspected that you'd ask me to do this. :-) No problem. I'll set it to run with - and wait for the next trigger. Ritesh -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com Necessity is the mother of invention. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526614: fdm dies trying to deliver via | sendmail
Yes, it is probably because it is setuid. fdm calls kill(pid, 0) to see if the
process has actually started. This isn't actually needed, it is a debugging
aid. In any case, if it gets EPERM it is probably safe to assume the process
does exist. Please try this diff:
Index: command.c
===
RCS file: /cvsroot/fdm/fdm/command.c,v
retrieving revision 1.53
diff -u -p -r1.53 command.c
--- command.c 1 Apr 2008 21:02:22 - 1.53
+++ command.c 4 May 2009 14:37:04 -
@@ -140,9 +140,10 @@ cmd_start(const char *s, int flags, cons
/* XXX Check if the child has actually started. */
if (kill(cmd-pid, 0) != 0) {
- if (errno != ESRCH)
+ if (errno == ESRCH)
+ CMD_DEBUG(cmd, child not running);
+ else if (errno != EPERM)
fatal(kill);
- CMD_DEBUG(cmd, child not running);
}
/* Parent. */
On Mon, May 04, 2009 at 03:33:26PM +0200, Frank Terbeck wrote:
[ Ccing the fdm-users mailing list. Please reply to all addresses in ]
[ To: and Cc: in order to keep all involved parties and the debian ]
[ BTS in the loop. ]
Ian Zimmerman i...@buug.org:
Package: fdm
Version: 1.5-3
Severity: normal
I tried to make fdm deliver directly to sendmail (exim actually) with a
config
line like this:
action default pipe /usr/sbin/sendmail -oi -odi i...@localhost
match all action default
but i get this in the log:
May 2 00:35:01 matica fdm[7686]: fatal: cmd_start: kill: Operation not
permitted
May 2 00:35:02 matica fdm[7675]: fatal: main: child socket closed
May 2 00:35:02 matica fdm[7676]: fatal: fetch_poll: parent socket closed
May 2 00:35:07 matica fdm[7678]: fatal: child_deliver: privsep_send error
and .fdm.lock stays around :-(
I reverted to the grotty fetchmail way (SMTP to localhost) and that works.
Maybe it has something to do with exim being setuid root?
Since I don't use any pipe actions myself, I'm clueless here.
Is this something that was addressed since fdm 1.5 was released? Are
there any workarounds?
Regards, Frank
--
Register Now Save for Velocity, the Web Performance Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
___
fdm-users mailing list
fdm-us...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fdm-users
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525121: fdm: leave mail on server
I'm not convinced by your version, it needs to explicitly state that all mail from this account is kept, even if you later tell it to drop the same mail in your rules. I'll have a closer look at the wording later on. 2009/4/22 Ritesh Raj Sarraf r...@researchut.com: On Wednesday 22 Apr 2009 17:30:03 Frank Terbeck wrote: My email account is on an exchange server that I access through IMAP. I also download a copy of the emails from the exachange server using POP3, for backup purpose. With fdm, when I pull the emails through POP3, it downloads emails, and then deletes them on the server. You can always use the 'keep' option to accounts or the action of the same name for individual rules. This is what the fdm.conf manpage says: The disabled keyword instructs fdm(1) to ignore this account unless it is explicitly enabled with a -a option on the command line. If the keep keyword is specified, all mail collected from this account is kept (not deleted) even if it matches a drop action. all mail collected .. is kept even it it matches a drop action This isn't very clear in my opinion. Especially because of the matches a dropt aciton statement. How about: If the keep keyword is specified, a copy of every email collected from this account is kept (not deleted) on the server. Ritesh -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com Necessity is the mother of invention. -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ fdm-users mailing list fdm-us...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fdm-users -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525121: fdm: leave mail on server
fdm doesn't keep track of mail it has seen unless you tell it to. Due to limitations in POP3 it requires a separate cache file (IMAP does not require one). Look for new-only and old-only in the manual, IIRC they have been there since about 1.4... I've been slacking on fdm recently so they certainly haven't been added after the latest release. As ft says you can use keep to tell fdm not to delete the mail after it has been fetched, but it will of course fetch it again next time unless you use new-only. 2009/4/22 Frank Terbeck f...@bewatermyfriend.org: Ccing the fdm-users mailing list, for additional input on the 'only' option, which I have no real experience with; and maybe inside about a possible new upstream release. Please reply to all addresses in To: and Cc: in order to keep all involved parties and the debian BTS in the loop. Here is the conversation on debian bug #525121 so far: Ritesh Raj Sarraf r...@researchut.com: My email account is on an exchange server that I access through IMAP. I also download a copy of the emails from the exachange server using POP3, for backup purpose. With fdm, when I pull the emails through POP3, it downloads emails, and then deletes them on the server. You can always use the 'keep' option to accounts or the action of the same name for individual rules. I somehow was able to restore my inbox folder on the exchange server. But then, on next fetch, it again attempts to download all the messages that it already had downloaded previously. Shouldn't fdm be keeping track of already downloaded messages? In fdm's CVS version (not yet released), there is an option called 'only', which can do what you're looking for, AFAICS. I would have to investigate if it is possible to backport that feature to the 1.6 package, which is available. Otherwise the only options here are waiting for upstream to do a new stable release or packaging a CVS snapshot. I'd be very much in favour of an upstream release here. And how do I tell fdm to leave a copy of the message that it is downloading ? As mentioned above the 'keep' keyword in various places can do what you are looking for. See the fdm.conf(5) manpage for this. Regards, Frank -- In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away. -- RFC 1925 -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ fdm-users mailing list fdm-us...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fdm-users -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525121: fdm: leave mail on server
The cache doesn't expire, otherwise it would refetch mail.
I should really convert this and the NNTP cache to reuse the generic
cache code which does support expiry.
2009/4/22 Ritesh Raj Sarraf r...@researchut.com:
On Wednesday 22 Apr 2009 23:17:56 Nicholas Marriott wrote:
fdm doesn't keep track of mail it has seen unless you tell it to. Due
to limitations in POP3 it requires a separate cache file (IMAP does
not require one). Look for new-only and old-only in the manual, IIRC
they have been there since about 1.4... I've been slacking on fdm
recently so they certainly haven't been added after the latest
release.
As ft says you can use keep to tell fdm not to delete the mail after
it has been fetched, but it will of course fetch it again next time
unless you use new-only.
Yes, the bug report was for that part of the problem itself. I have new-only
defined in my settings, but still it downloaded the same emails again..
here's my settings:
account company-pop3 disabled pop3
server company.hostname.com
user rrs
pass password
new-only cache ${base}/company-cache
keep
keep was the only new keyword I added today. Otherwise everything was
there before. But still it re-downloaded messages. I am going to test it
again tomorrow to confirm the behavior.
BTW, does the cache expire ever ?
Ritesh
--
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
Necessity is the mother of invention.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525121: fdm: leave mail on server
Er, sorry, that was unclear. It doesn't expire, but any mail found no
longer to be in the account should be removed from the cache, so if
you delete the mail with another program fdm should remove it from the
cache.
2009/4/22 Nicholas Marriott nicholas.marri...@gmail.com:
The cache doesn't expire, otherwise it would refetch mail.
I should really convert this and the NNTP cache to reuse the generic
cache code which does support expiry.
2009/4/22 Ritesh Raj Sarraf r...@researchut.com:
On Wednesday 22 Apr 2009 23:17:56 Nicholas Marriott wrote:
fdm doesn't keep track of mail it has seen unless you tell it to. Due
to limitations in POP3 it requires a separate cache file (IMAP does
not require one). Look for new-only and old-only in the manual, IIRC
they have been there since about 1.4... I've been slacking on fdm
recently so they certainly haven't been added after the latest
release.
As ft says you can use keep to tell fdm not to delete the mail after
it has been fetched, but it will of course fetch it again next time
unless you use new-only.
Yes, the bug report was for that part of the problem itself. I have new-only
defined in my settings, but still it downloaded the same emails again..
here's my settings:
account company-pop3 disabled pop3
server company.hostname.com
user rrs
pass password
new-only cache ${base}/company-cache
keep
keep was the only new keyword I added today. Otherwise everything was
there before. But still it re-downloaded messages. I am going to test it
again tomorrow to confirm the behavior.
BTW, does the cache expire ever ?
Ritesh
--
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
Necessity is the mother of invention.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525121: fdm: leave mail on server
Okay, I missed that. Hmm.
Can you show me the cache and the - output of a fetch where it is
refetching stuff in the cache? Don't forget to either strip passwords
or send it privately.
2009/4/22 Ritesh Raj Sarraf r...@researchut.com:
On Wednesday 22 Apr 2009 23:17:56 Nicholas Marriott wrote:
fdm doesn't keep track of mail it has seen unless you tell it to. Due
to limitations in POP3 it requires a separate cache file (IMAP does
not require one). Look for new-only and old-only in the manual, IIRC
they have been there since about 1.4... I've been slacking on fdm
recently so they certainly haven't been added after the latest
release.
As ft says you can use keep to tell fdm not to delete the mail after
it has been fetched, but it will of course fetch it again next time
unless you use new-only.
Yes, the bug report was for that part of the problem itself. I have new-only
defined in my settings, but still it downloaded the same emails again..
here's my settings:
account company-pop3 disabled pop3
server company.hostname.com
user rrs
pass password
new-only cache ${base}/company-cache
keep
keep was the only new keyword I added today. Otherwise everything was
there before. But still it re-downloaded messages. I am going to test it
again tomorrow to confirm the behavior.
BTW, does the cache expire ever ?
Ritesh
--
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
Necessity is the mother of invention.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
