aboutsummaryrefslogtreecommitdiffstats
path: root/worker/imap/seqmap.go
Commit message (Collapse)AuthorAgeFilesLines
* imap: create copy of uids to retain sort orderTim Culverhouse2022-08-221-1/+2
| | | | | | | | | | | | | Commit fdfec2c07a8d seqmap: refactor seqmap to use slice instead of map introduced a regression to imap sorting (if supported). The slice passed to seqmap was being sorted in place by UID, thus breaking any sort order sent by the server. Create a copy of the slice to retain the sort order reported to the UI while also keeping a correct map for seqnum -> UID in the worker. Signed-off-by: Tim Culverhouse <tim@timculverhouse.com> Acked-by: Robin Jarry <robin@jarry.cc>
* seqmap: refactor seqmap to use slice instead of mapTim Culverhouse2022-08-031-26/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The imap worker's seqmap is represented as a map of sequence number to UID. This presents a problem when expunging group of messages from the mailbox: each individual expunge decrements the sequence numbers by 1 (for every sequence number greater than the expunged). This requires a looping around the map to update the keys. The use of a map also requires that both the sequence number and the UID of a message be known in order to insert it into the map. This is only discovered by fetching individual message body parts (flags, headers, etc), leaving the seqmap to be empty until we have fetched information about each message. In certain instances (if a mailbox has recently been loaded), all information is loaded in memory and no new information is fetched - leaving the seqmap empty and the UI out of sync with the worker. Refactor the seqmap as a slice, so that any expunge automatically decrements the rest of the sequences. Use the results of FetchDirectoryContents or FetchDirectoryThreaded to initialize the seqmap with all discovered UIDs. Sort the UIDs in ascending order: IMAP specification requires that sequence numbers start at 1 increase in order of ascending UID. Add individual messages to the map if they come via a MessageUpdate and have a sequence number larger than our slice. Update seqmap tests with new logic. Reference: https://datatracker.ietf.org/doc/html/rfc3501#section-2.3.1.2 Fixes: https://todo.sr.ht/~rjarry/aerc/69 Signed-off-by: Tim Culverhouse <tim@timculverhouse.com> Acked-by: Robin Jarry <robin@jarry.cc>
* seqmap: sync seqNum to uid after expungeTim Culverhouse2022-07-241-2/+14
| | | | | | | | | | | | | | This patch updates the seqNums after an Expunge operation. When an expunge operation occurs, the seqNum of the deleted message is reported. The Imap spec [0] states that an immediate decrement of all seqnums greater than the deleted occurs, even before the next reporting of an expunge update. [0]: https://datatracker.ietf.org/doc/html/rfc3501#section-7.4.1 Fixes: https://todo.sr.ht/~rjarry/aerc/61 Signed-off-by: Tim Culverhouse <tim@timculverhouse.com> Signed-off-by: Robin Jarry <robin@jarry.cc>
* imap: fix data race on seqMap arrayRobin Jarry2022-06-241-0/+48
There are concurrent threads that are accessing and modifying IMAPWorker.seqMap (the mapping of sequence numbers to message UIDs). This can lead to crashes when trying to add and remove a message ID. panic: runtime error: index out of range [391] with length 390 goroutine 1834 [running]: git.sr.ht/~rjarry/aerc/logging.PanicHandler() logging/panic-logger.go:47 +0x6de panic({0xa41760, 0xc0019b3290}) /usr/lib/golang/src/runtime/panic.go:838 +0x207 git.sr.ht/~rjarry/aerc/worker/imap.(*IMAPWorker).handleFetchMessages.func1() worker/imap/fetch.go:214 +0x185 created by git.sr.ht/~rjarry/aerc/worker/imap.(*IMAPWorker).handleFetchMessages worker/imap/fetch.go:209 +0x12b Use a map which makes more sense than a simple array for random access operations. Also, it allows better typing for the key values. Protect the map with a mutex. Add internal API to access the map. Add basic unit tests to ensure that concurrent access works. Fixes: https://todo.sr.ht/~rjarry/aerc/49 Signed-off-by: Robin Jarry <robin@jarry.cc> Acked-by: Moritz Poldrack <moritz@poldrack.dev>