notmuch is limited to a single local mail store, right?

notmuch is limited to a single local mail store, right?

[myglc2]

After more flailing than I care to admit I have notmuch working with
nnir so that I can do 'G G' on a maildir folder populated/syncronized
by, for example, mbsync. Pretty, pretty, pretty nice!

In the process of getting this working, I discovered that, to use
notmuch, you must first consolidate all your mail under a single
directory which also holds the '.nogmuch' index folder.

Why? Because (according to the notmuch man page) '.notmuch-config'
specifies a single 'database.path' to maildir (as opposed to a list of
paths) and 'nnir-notmuch-remove-prefix' is a global variable.

I found it confusing that gnus lets you have multiple maildir folders
fronted by multiple nnmaildir "servers" but nnir + notmuch can search
only one. Or, in other words, 'G G' will work on one maildir group but
fail on the others.

So, now I'm guessing, "I am probably the only one who thinks multiple
maildirs are cool."

Anyway, I can work with this but I would like to check, does my
understanding sound correct to others?

If so, Do you think the gnus doc should clarify the point, and,
where/how would I suggest such a change?

Many thanks, George

Re: notmuch is limited to a single local mail store, right?

[Eric Abrahamsen]

myglc2 <myglc2@gmail.com> writes:

> After more flailing than I care to admit I have notmuch working with
> nnir so that I can do 'G G' on a maildir folder populated/syncronized
> by, for example, mbsync. Pretty, pretty, pretty nice!
>
> In the process of getting this working, I discovered that, to use
> notmuch, you must first consolidate all your mail under a single
> directory which also holds the '.nogmuch' index folder.
>
> Why? Because (according to the notmuch man page) '.notmuch-config'
> specifies a single 'database.path' to maildir (as opposed to a list of
> paths) and 'nnir-notmuch-remove-prefix' is a global variable.

Actually you can set that variable on individual servers, so each server
removes its own prefix.

You still have the problem that notmuch only indexes from a single
parent directory down, though. Have you already collected all your
various maildir servers under one parent directory?

Of course, you'll probably still run into errors: searching on one
server will cause notmuch to return results from *all* servers, then the
server under point will try to remove its prefix from all the results,
and... I don't know what will happen then!

E

Re: notmuch is limited to a single local mail store, right?

[Adam Sjøgren]

myglc2 writes:

> I found it confusing that gnus lets you have multiple maildir folders
> fronted by multiple nnmaildir "servers" but nnir + notmuch can search
> only one.

Why? Gnus and notmuch are separate projects with different concepts and
ideas.

If you have separate servers, I guess you can have a separate notmuch
index per server?

I would think that you would lose the ability to search across the
servers/indexes, but maybe that is what you want, when you split them
up?


  Best regards,

    Adam

-- 
 "We get our thursdays from a banana."                        Adam Sjøgren
                                                         asjo@koldfront.dk

Re: notmuch is limited to a single local mail store, right?

[Alan Schmitt]

[-- Attachment #1: Type: text/plain, Size: 634 bytes --]

On 2016-01-15 06:30, asjo@koldfront.dk (Adam Sjøgren) writes:

> I would think that you would lose the ability to search across the
> servers/indexes, but maybe that is what you want, when you split them
> up?

You can still craft a nnir request that spans over several servers. Here
is what I do to search my two local dovecot servers:

(global-set-key
 (kbd "<apps> M")
 (lambda () (interactive)
   (gnus-group-make-nnir-group nil '((nnir-group-spec . (("nnimap:inria") ("nnimap:local")))))))

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7
Athmospheric CO₂ (Updated January 13, 2016, Mauna Loa Obs.): 401.97 ppm

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

Re: notmuch is limited to a single local mail store, right?

[Adam Sjøgren]

Alan writes:

> On 2016-01-15 06:30, asjo@koldfront.dk (Adam Sjøgren) writes:
>
>> I would think that you would lose the ability to search across the
>> servers/indexes, but maybe that is what you want, when you split them
>> up?

> You can still craft a nnir request that spans over several servers. Here
> is what I do to search my two local dovecot servers:

> (global-set-key
>  (kbd "<apps> M")
>  (lambda () (interactive)
>    (gnus-group-make-nnir-group nil '((nnir-group-spec . (("nnimap:inria") ("nnimap:local")))))))

Very cool! - Problem solved :-)


  /A

-- 
 "Fish swim, birds fly,                                       Adam Sjøgren
  daddy's yell, mama's cry                               asjo@koldfront.dk
  old men sit and think
  I drink"

Re: notmuch is limited to a single local mail store, right?

[myglc2]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> myglc2 <myglc2@gmail.com> writes:
>
>> After more flailing than I care to admit I have notmuch working with
>> nnir so that I can do 'G G' on a maildir folder populated/syncronized
>> by, for example, mbsync. Pretty, pretty, pretty nice!
>>
>> In the process of getting this working, I discovered that, to use
>> notmuch, you must first consolidate all your mail under a single
>> directory which also holds the '.nogmuch' index folder.
>>
>> Why? Because (according to the notmuch man page) '.notmuch-config'
>> specifies a single 'database.path' to maildir (as opposed to a list of
>> paths) and 'nnir-notmuch-remove-prefix' is a global variable.
>
> Actually you can set that variable on individual servers, so each server
> removes its own prefix.

Thanks, you are right. But as you point out below, it is possibly
delusional to do so.

> You still have the problem that notmuch only indexes from a single
> parent directory down, though. Have you already collected all your
> various maildir servers under one parent directory?

Not yet. I am checking my assumptions first. Didn't want to collect them
if I didn't have to.

> Of course, you'll probably still run into errors: searching on one
> server will cause notmuch to return results from *all* servers, then the
> server under point will try to remove its prefix from all the results,
> and... I don't know what will happen then!
>
> E
Right, this is the crux of the problem, and why it seems that, for
practical use, one would want to consolidate mail under a single folder.

Re: notmuch is limited to a single local mail store, right?

[myglc2]

asjo@koldfront.dk (Adam Sjøgren) writes:

> myglc2 writes:
>
>> I found it confusing that gnus lets you have multiple maildir folders
>> fronted by multiple nnmaildir "servers" but nnir + notmuch can search
>> only one.
>
> Why? Gnus and notmuch are separate projects with different concepts and
> ideas.

Right, of course.

> If you have separate servers, I guess you can have a separate notmuch
> index per server?

notmuch does not support making more than one index.

> I would think that you would lose the ability to search across the
> servers/indexes, but maybe that is what you want, when you split them
> up?

I was thinking I wanted to split them up for backup and other purposes.

Re: notmuch is limited to a single local mail store, right?

[myglc2]

asjo@koldfront.dk (Adam Sjøgren) writes:

> Alan writes:
>
>> On 2016-01-15 06:30, asjo@koldfront.dk (Adam Sjøgren) writes:
>>
>>> I would think that you would lose the ability to search across the
>>> servers/indexes, but maybe that is what you want, when you split them
>>> up?
>
>> You can still craft a nnir request that spans over several servers. Here
>> is what I do to search my two local dovecot servers:
>
>> (global-set-key
>>  (kbd "<apps> M")
>>  (lambda () (interactive)
>>    (gnus-group-make-nnir-group nil '((nnir-group-spec
>>  . (("nnimap:inria")
>>     ("nnimap:local")))))))

Thanks, but, practically speaking, this approach can not work with two
maildir stores and notmuch, because notmuch can only index one of them.

I guess it should work if a second search engine (e.g. namazu) is used
for the second maildir. This seems a bit silly to recommend. I will see
how it works if/when I get namazu working.

Re: notmuch is limited to a single local mail store, right?

[Erik Colson]

Hi..

I've followed this thread and although I can understand your technical
problem, I still am questioning myself about why 1 user would want two
or more separate Maildir structures on a single system ?

best
-- 
erik colson

Re: notmuch is limited to a single local mail store, right?

[Peter Münster]

On Fri, Jan 15 2016, myglc2 wrote:

> notmuch does not support making more than one index.

What about:
NOTMUCH_CONFIG=here  notmuch
NOTMUCH_CONFIG=there notmuch
?

-- 
           Peter

Re: notmuch is limited to a single local mail store, right?

[myglc2]

Erik Colson <eco@ecocode.net> writes:

> I've followed this thread and although I can understand your technical
> problem, I still am questioning myself about why 1 user would want two
> or more separate Maildir structures on a single system ?

Hi Erik,

Thanks for the question. I want to sync multiple email accounts into
local stores. I was thinking each local store would be a "virtual
server" in *Server*.

Since I have multiple accounts with different modes of use, I imagine
the benefits of this scheme would be to allow different and independent
ways of syncing, storing, backing up, indexing and searching the local
stores.

Are there downsides to this approach (other than that notmuch doesn't
support it) that I am missing?

Or are there benefits to putting them all in one maildir that I am
missing?

Thanks - George

Re: notmuch is limited to a single local mail store, right?

[Adam Sjøgren]

myglc2 writes:

>> If you have separate servers, I guess you can have a separate notmuch
>> index per server?

> notmuch does not support making more than one index.

Uhm, you don't have to tell one notmuch instance about the other?

Just run notmuch once against one "server" (using one configuration),
and then run it against the other "server" (using a second
configuration).

The two notmuch indexes won't know about eachother, of course, but
nothing stops you from doing this - just use the --config=FILE command
line option.

>> I would think that you would lose the ability to search across the
>> servers/indexes, but maybe that is what you want, when you split them
>> up?

> I was thinking I wanted to split them up for backup and other purposes.

That makes sense - I was trying to ask you about when you search for
something, do you want to search only within a single "server"?

If so, having a notmuch index for each "server" will not be a problem.
If you want to search across "servers", you'll need something like what
Alan Schmitt wrote.


  Best regards,

    Adam

-- 
 "Sleepwalking!" "Nightmare!"                                 Adam Sjøgren
 "Homocidal psycho jungle cat!"                          asjo@koldfront.dk

Re: notmuch is limited to a single local mail store, right?

[Adam Sjøgren]

myglc2 writes:

>> If you have separate servers, I guess you can have a separate notmuch
>> index per server?

> notmuch does not support making more than one index.

I think you are overinterpreting in this statement.

>> I would think that you would lose the ability to search across the
>> servers/indexes, but maybe that is what you want, when you split them
>> up?

> I was thinking I wanted to split them up for backup and other purposes.

Makes sense to me :-)


  Best regards,

    Adam

-- 
 "I think geniuses should be given special                    Adam Sjøgren
  considerations."                                       asjo@koldfront.dk

Re: notmuch is limited to a single local mail store, right?

[myglc2]

Peter Münster <pmlists@free.fr> writes:

> On Fri, Jan 15 2016, myglc2 wrote:
>
>> notmuch does not support making more than one index.
>
> What about:
> NOTMUCH_CONFIG=here  notmuch
> NOTMUCH_CONFIG=there notmuch
> ?

asjo@koldfront.dk (Adam Sjøgren) writes:

> On Fri, Jan 15 2016, myglc2 wrote:
>
>> notmuch does not support making more than one index.
>
> I think you are overinterpreting in this statement.

OOPS! Hey, many thanks for straightening me out on this.

So... I tried passing notmuch config in as a switch like so ...

;; notmuch on 2nd test maildir folder
  (add-to-list 'gnus-secondary-select-methods
	       '(nnmaildir "foobar.2"
			   (directory "~/Maildir/foobar.2")
			   (nnir-search-engine notmuch)
			   (nnir-notmuch-remove-prefix
			    "/home/glc/Maildir/foobar.2/")
			   (nnir-notmuch-additional-switches
			    '("--config=/home/glc/.notmuch-config.2")
			    )
			   )
	       )

... and discovered two issues. When I followed the help setting the
switches ...

  ;; nnir-notmuch-additional-switches is a variable defined in ‘nnir.el’.
  ;; Its value is nil
  ;;
  ;; Documentation:
  ;; *A list of strings, to be given as additional arguments to notmuch.
  ;;
  ;; Note that this should be a list.  I.e., do NOT use the following:
  ;;     (setq nnir-notmuch-additional-switches "-i -w") ; wrong
  ;; Instead, use this:
  ;;     (setq nnir-notmuch-additional-switches '("-i" "-w"))

... there was a spurious 'quote( )' passed to notmuch. So ... I removed
the leading quote, and the argument list shown in the message buffer
looked better. So maybe the help should be changed to read ...

  ;; Instead, use this:
  ;;     (setq nnir-notmuch-additional-switches ("-i" "-w"))

However, The order in which the additional switches are passed ...


notmuch args: search --format=text --output=files --config=/home/glc/.notmuch-config.2 olivia
Massaging notmuch output...done
Search produced empty results.

... and as constructed by this nnir.el code ...

      (let* ((cp-list `( ,nnir-notmuch-program
                         nil            ; input from /dev/null
                         t              ; output
                         nil            ; don't redisplay
                         "search"
                         "--format=text"
                         "--output=files"
                         ,@(nnir-read-server-parm 'nnir-notmuch-additional-switches server)
                         ,qstring       ; the query, in notmuch format
                         ))

... made notmuch unhappy. So I 'fixed' nnir-run-notmuch by changing the
order ...

      (let* ((cp-list `( ,nnir-notmuch-program
                         nil            ; input from /dev/null
                         t              ; output
                         nil            ; don't redisplay
                         ,@(nnir-read-server-parm 'nnir-notmuch-additional-switches server)
                         "search"
                         "--format=text"
                         "--output=files"
                         ,qstring       ; the query, in notmuch format
                         ))

... which made notmuch happy ...

notmuch args: --config=/home/glc/.notmuch-config.2 search --format=text
--output=files olivia Massaging notmuch output...done

So... Bottom line, a gnus config like this ...

;; notmuch on 2nd test maildir folder
  (add-to-list 'gnus-secondary-select-methods
	       '(nnmaildir "foobar.2"
			   (directory "~/Maildir/foobar.2")
			   (nnir-search-engine notmuch)
			   (nnir-notmuch-program "notmuch")
			   (nnir-notmuch-remove-prefix
			    "/home/glc/Maildir/foobar.2/")
			   (nnir-notmuch-additional-switches
			    ("--config=/home/glc/.notmuch-config.2")
			    )
			   )
	       )

... with the minor change to nnir.el shown above, allows multiple
notmuch indexes.

BTW, I also tried the 'NOTMUCH_CONFIG=here notmuch' scheme suggested by
Peter hoping it might not require any code changes. I tried this ...

  ;; notmuch on 3rdd test maildir folder
  (add-to-list 'gnus-secondary-select-methods
  	       '(nnmaildir "foobar.3"
  			   (directory "~/Maildir/foobar.3")
  			   (nnir-search-engine notmuch)
			   ;; Note: this fails because 'call-process'
			   ;; punts on the environmental var
  			   (nnir-notmuch-program
			    "NOTMUCH_CONFIG=${HOME}/.notmuch-config.3 notmuch")
  			   (nnir-notmuch-remove-prefix
  			    "/home/glc/Maildir/foobar.3/")
  			   )
  	       )

But I discovered that a global value of nnir-notmuch-program is used by
nnir-run-notmuch. I did a little hack to pick up the server-specific
value like so ...

      (let* ((cp-list `(,(nnir-read-server-parm 'nnir-notmuch-program server)
                         nil            ; input from /dev/null
                         t              ; output
                         nil            ; don't redisplay
                         ,@(nnir-read-server-parm 'nnir-notmuch-additional-switches server)
                         "search"
                         "--format=text"
                         "--output=files"
                         ,qstring       ; the query, in notmuch format
                         ))

... but then ...

                (apply 'call-process cp-list))))

... produced this error ...

c-append-to-state-cache: Searching for program: No such file or
directory, NOTMUCH_CONFIG=${HOME}/.notmuch-config.3 notmuch

So... how do one pass an environmental from an init file into a process?

Many thanks, - George

Re: notmuch is limited to a single local mail store, right?

[myglc2]

myglc2 <myglc2@gmail.com> writes:

> asjo@koldfront.dk (Adam Sjøgren) writes:
>
>> Alan writes:
>>
>>> On 2016-01-15 06:30, asjo@koldfront.dk (Adam Sjøgren) writes:
>>>
>>>> I would think that you would lose the ability to search across the
>>>> servers/indexes, but maybe that is what you want, when you split them
>>>> up?
>>
>>> You can still craft a nnir request that spans over several servers. Here
>>> is what I do to search my two local dovecot servers:
>>
>>> (global-set-key
>>>  (kbd "<apps> M")
>>>  (lambda () (interactive)
>>>    (gnus-group-make-nnir-group nil '((nnir-group-spec
>>>  . (("nnimap:inria")
>>>     ("nnimap:local")))))))
>
> Thanks, but, practically speaking, this approach can not work with two
> maildir stores and notmuch, because notmuch can only index one of them.

With helpful guidance from others, I have discovered that this statement
is fundamentally wrong. Sorry.

Notmuch can actually handle multiple stores, and, with a minor patch to
nnir.el, described in a separate post, your approach can be applied to
multiple maildir stores indexed by notmuch.

gnus async prefetch and nnimap

[Erik Colson]

Hi,

I was playing with asynch prefetch and got it to work for nntp
newsgroups. However it doesn't seem to work on nnimap groups. Any reason
for this ? Or am I missing something ?

best
-- 
erik colson

Re: gnus async prefetch and nnimap

[Eric Abrahamsen]

Erik Colson <eco@ecocode.net> writes:

> Hi,
>
> I was playing with asynch prefetch and got it to work for nntp
> newsgroups. However it doesn't seem to work on nnimap groups. Any reason
> for this ? Or am I missing something ?

Asynchronicity isn't enabled for nnimap -- I don't know if that's just
because no one went and enabled it, or if there's some fundamental
reason it won't work with IMAP. If you're adventurous, I suppose you
could add:

(deffoo nntp-asynchronous-p ()
  t)

To nnimap.el, and recompile/reload/restart, and see what happens. It
would make me nervous!

Eric

Re: gnus async prefetch and nnimap

[Eric Abrahamsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Erik Colson <eco@ecocode.net> writes:
>
>> Hi,
>>
>> I was playing with asynch prefetch and got it to work for nntp
>> newsgroups. However it doesn't seem to work on nnimap groups. Any reason
>> for this ? Or am I missing something ?
>
> Asynchronicity isn't enabled for nnimap -- I don't know if that's just
> because no one went and enabled it, or if there's some fundamental
> reason it won't work with IMAP. If you're adventurous, I suppose you
> could add:
>
> (deffoo nntp-asynchronous-p ()
>   t)

Bah, should have been nnimap-asynchronous-p, of course.

IMAP changes timestamp when moving an article to another group

[Erik Colson]

Hello,

When I use gnus-summary-move-article [Bm] to move an article into
another group on a dovecot imap server, the timestamp in other clients
gets changed to actual date/time. The header of the article still
represents the correct timestamp though (and so does gnus). But the
timestamp is faulty when accessing the group through Mail.app on my Mac.

Is this dovecot related ? or can I configure gnus somehow to not change
the timestamp ? For info, when moving mail between groups from within
Mail.app everything is handled correctly (also in gnus).

Thanks for help !
-- 
erik colson

Re: IMAP changes timestamp when moving an article to another group

[Greg Troxel]

[-- Attachment #1: Type: text/plain, Size: 1364 bytes --]


Erik Colson <eco@ecocode.net> writes:

> When I use gnus-summary-move-article [Bm] to move an article into
> another group on a dovecot imap server, the timestamp in other clients
> gets changed to actual date/time. The header of the article still
> represents the correct timestamp though (and so does gnus). But the
> timestamp is faulty when accessing the group through Mail.app on my Mac.

I have noticed this as well, but I was never clear on whether the
received date was wrong or if it was just that clients other than gnus
were sorting on the wrong date.

This seems to be the IMAP received tiemstamp:

http://serverfault.com/questions/588618/maintain-email-timestamp-when-transferring-between-email-servers-using-an-email

http://www.dovecot.org/list/dovecot/2008-July/032165.html


> Is this dovecot related ? or can I configure gnus somehow to not change
> the timestamp ? For info, when moving mail between groups from within
> Mail.app everything is handled correctly (also in gnus).

As I understand it from the dovecot mail message above, gnus should
probably use APPEND when moving and set the date to match the source
message.

Another view is that the current behavior is right because the message's
received date is the time it was copied into the account.

But, I think preserving the received date on copy is probably more
useful overall.




[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 180 bytes --]

Re: IMAP changes timestamp when moving an article to another group

[Steinar Bang]

>>>>> Greg Troxel <gdt@lexort.com>:

> But, I think preserving the received date on copy is probably more
> useful overall.

Agreed.  

Or actually, I would say it even stronger: preserving the received date
on copy is the only correct behaviour.

Re: IMAP changes timestamp when moving an article to another group

[Erik Colson]

Steinar Bang <sb@dod.no> writes:

>>>>>> Greg Troxel <gdt@lexort.com>:
>
>> But, I think preserving the received date on copy is probably more
>> useful overall.
>
> Agreed.  
>
> Or actually, I would say it even stronger: preserving the received date
> on copy is the only correct behaviour.

Hello.

This would indeed solve my problem.
How can I file this as a feature request ?

best
-- 
erik colson

Re: IMAP changes timestamp when moving an article to another group

[Steinar Bang]

>>>>> On Tue, 16 Aug 2016 15:22:46 +0200, Erik Colson <eco@ecocode.net> said:
> Steinar Bang <sb@dod.no> writes:
>>>>>>> Greg Troxel <gdt@lexort.com>:

>>> But, I think preserving the received date on copy is probably more
>>> useful overall.

>> Agreed.  

>> Or actually, I would say it even stronger: preserving the received date
>> on copy is the only correct behaviour.

> This would indeed solve my problem.
> How can I file this as a feature request ?


Does anyone know what happened to this issue?

I haven't dared expire or move stuff in my nnimap folders for the last
year or so...

Re: IMAP changes timestamp when moving an article to another group

[Steinar Bang]

>>>>> Steinar Bang <sb@dod.no>:


> Does anyone know what happened to this issue?

> I haven't dared expire or move stuff in my nnimap folders for the last
> year or so...

To summarize: When expiring, or moving with "B m" messages between
nnimap on a dovecot server, the date is displayed wrongly in other IMAP
clients.

The Date: header on the message itself is unchanged, but the
INTERNALDATE gets the time of the move/copy operation.

Dovecot allows the INTERNALDATE to be specified during a copy (see Timo
Siriainens last reply text in [1]), and the feature request is that nnimap
specifices the INTERNALDATE during a copy.

I've looked at the git log of nnimap.el and it doesn't look like
anything related to this has been done since august 2016[2].

In fact, these two changes from march 2016 may be the cause of the date
not being preserved on move/expiry, since Timo Siriainen seems to
indicate that dovecot by default preserves the INTERNALDATE in a MOVE
between folders on the same server (see Timo Siriainens first reply text
in [1]), from the git log of nnimap.el:

commit d5427e71da28856c5e43396a37ffd0c906947499
Author: Lars Magne Ingebrigtsen <larsi@gnus.org>
Date:   Mon Mar 14 20:23:30 2016 +0100

    Disable MOVE more for Dovecot

    * lisp/gnus/nnimap.el (nnimap-process-expiry-targets): Also
    disable MOVE when expirying.
    (nnimap-split-incoming-mail): And when splitting mail.

commit 8ed27bdf88cab134c26f3609c4d11c574f74705c
Author: Lars Magne Ingebrigtsen <larsi@gnus.org>
Date:   Mon Mar 14 20:21:02 2016 +0100

    Don't use MOVE on Dovecot

    * lisp/gnus/nnimap.el (nnimap-request-move-article): Don't use
    MOVE on Dovecot, since it's broken in many versions.
    (nnimap-quirks): Mark MOVE on Dovecot as non-working.


References:
[1] <https://www.dovecot.org/list/dovecot/2008-July/032170.html>
[2] <http://git.savannah.gnu.org/cgit/emacs.git/log/lisp/gnus/nnimap.el>

Re: IMAP changes timestamp when moving an article to another group

[Eric Abrahamsen]

Steinar Bang <sb@dod.no> writes:

>>>>>> Steinar Bang <sb@dod.no>:
>
>
>> Does anyone know what happened to this issue?
>
>> I haven't dared expire or move stuff in my nnimap folders for the last
>> year or so...
>
> To summarize: When expiring, or moving with "B m" messages between
> nnimap on a dovecot server, the date is displayed wrongly in other IMAP
> clients.
>
> The Date: header on the message itself is unchanged, but the
> INTERNALDATE gets the time of the move/copy operation.
>
> Dovecot allows the INTERNALDATE to be specified during a copy (see Timo
> Siriainens last reply text in [1]), and the feature request is that nnimap
> specifices the INTERNALDATE during a copy.

I looked at the link, but I still don't really see where he's saying
that you can specify the INTERNALDATE. The IMAP specs certainly don't
indicate that any additional arguments are possible with a MOVE command.
You can specify a date with APPEND, but the only time Gnus uses that is
when replacing an article, not MOVEing (so far as I can tell)...

Re: IMAP changes timestamp when moving an article to another group

[Steinar Bang]

>>>>> Eric Abrahamsen <eric@ericabrahamsen.net>:

> I looked at the link, but I still don't really see where he's saying
> that you can specify the INTERNALDATE.

You're right.  I misread, he says that about the APPEND command.

> The IMAP specs certainly don't indicate that any additional arguments
> are possible with a MOVE command.

No, that was mbox-specific implementation on part of dovecot: if the
move command is used, the file is just moved from one directory to the
other (ie. on a GNU/linux filesystem: the inode is untouched) and mtime
is preserved, and therefore INTERNALDATE is preserved.

However in March 2016 in the git history of nnimap.el there were some
changes where Gnus stopped using MOVE on dovecot.

> You can specify a date with APPEND, but the only time Gnus uses that
> is when replacing an article, not MOVEing (so far as I can tell)...

Yes, I saw that when I was reading the specs of COPY yesterday (after I
had posted the message you're responding to).

However dovecot could (and really should) pick the date out of the Date
field of the source message when doing a COPY and use that as the mtime
of the new mbox file. 

Currently, I'm guessing, when dovecot w/mbox does a COPY, the mtime of
the message file in the mbox folder will become time the file was
created.

Re: IMAP changes timestamp when moving an article to another group

[Eric Abrahamsen]

Steinar Bang <sb@dod.no> writes:

>>>>>> Eric Abrahamsen <eric@ericabrahamsen.net>:
>
>> I looked at the link, but I still don't really see where he's saying
>> that you can specify the INTERNALDATE.
>
> You're right.  I misread, he says that about the APPEND command.
>
>> The IMAP specs certainly don't indicate that any additional arguments
>> are possible with a MOVE command.
>
> No, that was mbox-specific implementation on part of dovecot: if the
> move command is used, the file is just moved from one directory to the
> other (ie. on a GNU/linux filesystem: the inode is untouched) and mtime
> is preserved, and therefore INTERNALDATE is preserved.
>
> However in March 2016 in the git history of nnimap.el there were some
> changes where Gnus stopped using MOVE on dovecot.
>
>> You can specify a date with APPEND, but the only time Gnus uses that
>> is when replacing an article, not MOVEing (so far as I can tell)...
>
> Yes, I saw that when I was reading the specs of COPY yesterday (after I
> had posted the message you're responding to).
>
> However dovecot could (and really should) pick the date out of the Date
> field of the source message when doing a COPY and use that as the mtime
> of the new mbox file. 
>
> Currently, I'm guessing, when dovecot w/mbox does a COPY, the mtime of
> the message file in the mbox folder will become time the file was
> created.

Beats me, I guess... Is there a configuration knob you can twiddle in Dovecot?

Re: IMAP changes timestamp when moving an article to another group

[Steinar Bang]

>>>>> Eric Abrahamsen <eric@ericabrahamsen.net>:
> Steinar Bang <sb@dod.no> writes:

>> Currently, I'm guessing, when dovecot w/mbox does a COPY, the mtime
>> of the message file in the mbox folder will become time the file was
>> created.

Yes it will.  I just asked on the dovecot mailing list.

> Beats me, I guess... Is there a configuration knob you can twiddle in
> Dovecot?

I don't know. But I'm guessing that there isn't...?

And if there isn't, the only ways to preserve INTERNALDATE on folder
moves with nnimap in Gnus on dovecot with maildir, are:

 1. Go back to using MOVE for dovecot, ie. reverting the March 2016
    changes to Gnus:
     http://git.savannah.gnu.org/cgit/emacs.git/commit/lisp/gnus/nnimap.el?id=d5427e71da28856c5e43396a37ffd0c906947499
     http://git.savannah.gnu.org/cgit/emacs.git/commit/lisp/gnus/nnimap.el?id=8ed27bdf88cab134c26f3609c4d11c574f74705c

 2. Use APPEND instead of COPY so that INTERNALDATE can be specified 

Re: IMAP changes timestamp when moving an article to another group

[Eric Abrahamsen]

Steinar Bang <sb@dod.no> writes:

>>>>>> Eric Abrahamsen <eric@ericabrahamsen.net>:
>> Steinar Bang <sb@dod.no> writes:
>
>>> Currently, I'm guessing, when dovecot w/mbox does a COPY, the mtime
>>> of the message file in the mbox folder will become time the file was
>>> created.
>
> Yes it will.  I just asked on the dovecot mailing list.
>
>> Beats me, I guess... Is there a configuration knob you can twiddle in
>> Dovecot?
>
> I don't know. But I'm guessing that there isn't...?
>
> And if there isn't, the only ways to preserve INTERNALDATE on folder
> moves with nnimap in Gnus on dovecot with maildir, are:
>
>  1. Go back to using MOVE for dovecot, ie. reverting the March 2016
>     changes to Gnus:
>      http://git.savannah.gnu.org/cgit/emacs.git/commit/lisp/gnus/nnimap.el?id=d5427e71da28856c5e43396a37ffd0c906947499
>      http://git.savannah.gnu.org/cgit/emacs.git/commit/lisp/gnus/nnimap.el?id=8ed27bdf88cab134c26f3609c4d11c574f74705c
>
>  2. Use APPEND instead of COPY so that INTERNALDATE can be specified 

Hmm, the comments don't really say *what* brokenness the quirks were
meant to fix. I wouldn't feel confident at all in saying what the right
thing to do is. Maybe Lars will chime in...

Re: IMAP changes timestamp when moving an article to another group

[Lars Ingebrigtsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Hmm, the comments don't really say *what* brokenness the quirks were
> meant to fix. I wouldn't feel confident at all in saying what the right
> thing to do is. Maybe Lars will chime in...

Uhm uhm uhm ding ding chime.  I seem to vaguely recall that a version of
Dovecot was completely 100% broken for MOVE, but I don't recall any
further details.  The person who wrote those checkin messages should get
their act together; geez.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: IMAP changes timestamp when moving an article to another group

[Eric Abrahamsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Hmm, the comments don't really say *what* brokenness the quirks were
>> meant to fix. I wouldn't feel confident at all in saying what the right
>> thing to do is. Maybe Lars will chime in...
>
> Uhm uhm uhm ding ding chime.  I seem to vaguely recall that a version of
> Dovecot was completely 100% broken for MOVE, but I don't recall any
> further details.  The person who wrote those checkin messages should get
> their act together; geez.

I guess at some point it would be nice to fine-tune behavior a little
more for the various servers (though you're not supposed to do that),
but it might wait until finer-grained overrides are possible.