Marking all (many thousands) messages as read

[Jack Baty]

Somehow, in a recent mbsync-ing incident, all of my messages are now showing as unread. Is there a way to mark them _all_ as read in one fell swoop? I can do it 500 at a time (the query limit?) but there are maybe 75,000 messages and I'd like to find a faster way.

Thanks,

Jack

[Dirk-Jan C. Binnema]

One way (slightly hacky) way would be to `mv` them on the messages on
file-system level (each messages has its own file) from the
'folder/new/' directory to the 'folder/cur/' directory, and make sure
they get a ':2,S' suffix in the target location.

Try it by hand with a few first :-)

Kind regards,
Dirk.

--
Dirk-Jan C. Binnema Helsinki, Finland
e:dj...@djcbsoftware.nl w:www.djcbsoftware.nl
pgp: D09C E664 897D 7D39 5047 A178 E96A C7A1 017D DA3C

[Jack Baty]

I'll work up the courage to try that, thank you Dirk. :)

One note, the read files on my Mac end in '/2,S' rather than ':2,S'. Is that expected? The files on the Linux machine do end in ':2,S'.

I also noticed that on the Linux machine many of the files have an odd/missing character in the filename where the '/' or ':' should be.

I suspect that my copying of the ~/Mail directory from my Mac to Linux before syncing via mbsync may not have been the best idea. I'm thinking I might fix the filenames on my Mac, sync, then start fresh on the Linux box and sync there from scratch. If that seems like a terrible plan, do let me know!

Thanks again,

Jack

 

On Saturday, February 10, 2018 at 12:45:23 PM UTC-5, djcb wrote:

On Saturday Feb 10 2018, Jack Baty wrote:

> Somehow, in a recent mbsync-ing incident, all of my messages are now
> showing as unread. Is there a way to mark them _all_ as read in one fell
> swoop? I can do it 500 at a time (the query limit?) but there are maybe
> 75,000 messages and I'd like to find a faster way.

One way (slightly hacky) way would be to `mv` them on the messages on
file-system level (each messages has its own file) from the
'folder/new/' directory to the 'folder/cur/' directory, and make sure
they get a ':2,S' suffix in the target location.

Try it by hand with a few first :-)

Kind regards,
Dirk.

--
Dirk-Jan C. Binnema                  Helsinki, Finland

e:d...@djcbsoftware.nl           w:www.djcbsoftware.nl

[Yuri D'Elia]

On Sat, Feb 10 2018, Dirk-Jan C. Binnema wrote:
> One way (slightly hacky) way would be to `mv` them on the messages on
> file-system level (each messages has its own file) from the
> 'folder/new/' directory to the 'folder/cur/' directory, and make sure
> they get a ':2,S' suffix in the target location.
>
> Try it by hand with a few first :-)

I think I've filed a request for arbitrary labels/tags, but if I didn't,
please consider this as a formal request for the next mu ;)

notmuch heavily relies on tags to do batch processing. For example, with
just the ability to search/apply for tags given a query, I was able to
implement "adaptive killing" (gnus style) by assigning custom labels
when a message is read (using the read hook), and then processing the
results on the next mail fetch by searching all [related] messages with
those tags and assigning the "hidden" tags to them. All this without any
support from notmuch itself. Just some minor elisp customization.

I personally didn't like three things about notmuch:

- conflation of directories and tags. This distinction is vital for
message copies, imap syncing and deletion - I do *not* want to lose
the tree structure with a surrogate. mu does it right.
- the idea that everything should be shown grouped in a thread. nntp
clients taught me otherwise a long time ago. I still prefer gnus's
approach to mail here, but mu is message oriented and still ok to me.
- the "not much of a client" approach to the emacs notmuch interface.
I feel mu is a proper mail client, while notmuch is just a query
interface with stuff tacked on.

That being said, the notmuch backend strategy of using tags to do
customizable processing is *very* useful. It still has the issue that a
tag is local (cannot be synced via imap), but for everything that I
wanted to do was actually sufficient and didn't feel limiting.

[Marcin Borkowski]

How about setting up a keyboard macro, firing it up with a repeat count
and going for a long walk?

Hth,

--
Marcin Borkowski