search for: inconsistency

Hi, I am seeing inconsistencies in search results (finding 2 emails when only 1 exists, finding the email when it has been moved to another folder, etc). I figured I should run force-resync to fix any issues. I ran the following: doveadm -v force-resync -u <user> <mailbox> and I got some worrysome logs. - I should mention that I have been seeing some crashes of fts-lucene in my

Hello I have found this entries in my log /var/log/maillog.13.xz:Jun 6 17:03:26 buzon dovecot: imap(juanan): Error: mdbox /buzones//18/66/juanan/mailboxes/P7.Bielorrusia/cd-eslpod-enviado/dbox-Mails: Storage keeps breaking /var/log/maillog.108.xz:Mar 4 01:42:09 buzon dovecot: imap(lbandera): Error: mdbox /buzones/0b/11/lbandera/mailboxes/Sent/dbox-Mails: Storage keeps breaking

Yes, that would help too. Aki On 05.06.2017 14:35, awl1 wrote: > Hello Aki, > > sorry, but I am still a newbie to Dovecot: > > Hmm - I don't seem to have IMAP session IDs in every line of my > dovecot-info.log. that could be used to extract IMAP session-related > info. > > I assume that I have to set up logging in a specific way to add and > then find the IMAP

That log didn't do much help, can you try enabling mail_debug=yes for a moment and see if it gives any more insight? Aki On 05.06.2017 15:13, awl1 wrote: > Hello again, > > here you are (log excerpt from May 29 00:06:02 until May 29 01:17:49): > > May 29 00:12:05 imap(xxx at xxx.org): Info: IMAP session state is > inconsistent, please relogin. in=1369 out=222662 > May

Sorry, just one more thing I've just noticed now from looking at the IMAP session IDs: Dovecot seems to map the steps as outlined below to four different IMAP session IDs all related to the exact same Thunderbird client instance: * <yH0lKWRRpNHAqOh5> session for the folder copy of folder "Dilbert" with 317 messages * <VcMlLWRRqNHAqOh5> session for the deletion

I have seen some strange error log messages in our dovecot server (2.0.15, RHEL 5.7x64, mdbox+zlib, local storage, high load) Dec 14 22:01:27 buzon dovecot: imap(fmcarrasco): Error: /indices_dovecot/indices/07/47/fmcarrasco/mailboxes/INBOX/dovecot.index reset, view is now inconsistent Dec 14 22:00:27 buzon dovecot: imap(cfp): Error:

...we don't want to lose. I have observed the following behavior in the logs: When a new mail arrives: (The second line below is always the same, however there's no mail with uid 12819 according to doveadm search uid 12819) Mar 04 11:43:28 lda(user): Warning: mdbox /var/mail/user/storage: Inconsistency in map index (117,1060 != 117,1883660) Mar 04 11:43:28 lda(user): Error: Log synchronization error at seq=117,offset=1546660 for /var/mail/user/storage/dovecot.map.index: Extension record inc drops number below zero (uid=12819, diff=-1, orig=0) Mar 04 11:43:28 lda(user): Warning: fscking index fi...

I just checked out trunk/vorbis to build the latest libvorbis, and noticed an inconsistency in the project settings. For the two build configurations Debug and Release, we have as the Output Directory "$(SolutionDir)$(ConfigurationName)", and the Intermediate Directory "Debug". ("Release" for the Release configuration) However, for the two build configura...

Hello Aki, please find attached the debug log from another incident, this time with IMAP session ID (<yH0lKWRRpNHAqOh5>) in the logs and with "mail_debug=yes" in dovecot.conf. I can consistently reproduce the "inconsistent state" error message by the following steps from the most recent Thunderbird version (52.1.1, on 64-bit Linux Ubuntu 16.04.02 LTS): * copy a

Hello again, here you are (log excerpt from May 29 00:06:02 until May 29 01:17:49): May 29 00:12:05 imap(xxx at xxx.org): Info: IMAP session state is inconsistent, please relogin. in=1369 out=222662 May 29 00:12:05 imap(xxx at xxx.org): Info: IMAP session state is inconsistent, please relogin. in=204 out=1504 May 29 00:40:29 imap(xxx at xxx.org): Info: IMAP session state is inconsistent,

I noticed some undocumented and inconsistent behavior in device_Raster when a plot is produced with reflected axes such as: image(volcano, xlim = c(1,0), useRaster = TRUE) image(volcano, ylim = c(1,0), useRaster = TRUE) The `pdf` device will perform horizontal and vertical reflections, while `quartz` will ignore the transformations when plotting to the screen, but when plotting to a

...seems to be consistent with the output of a simple C program using the underlying strtol function (see data.table link for this program, and for full sessionInfo() of some environments with differing output). So, what is the correct output of strtoi("", base = 2L)? Is the cross-platform inconsistency to be expected/documentable? Michael Chirico [[alternative HTML version deleted]]

...[1,] 1 These seem to indicate that NULL parameters will be ignored in any call to cbind and rbind. However: > cbind(NULL, diag(x = 1, 0, 1)) [,1] [,2] I.e. if one dimension of another parameter to cbind/rbind is zero, cbind/rbind will create a row/column from the NULL parameter. This inconsistency creates problems in the construction of matrices within loops and similar constructs.

This inconsistency recently came to my attention: > df <- data.frame(A = 1:10, B = rnorm(10)) > min(df) [1] -1.768958 > max(df) [1] 10 > mean(df) [1] NA Warning message: In mean.default(df) : argument is not numeric or logical: returning NA I recall the times where `mean(df)` would give `colMeans(df)...

This question is more out of curiosity than a complaint or suggestion, but I'm just wondering. The behavior of R on calculations that result in NaN seems a bit inconsistent. # this is expected: > 0/0 [1] NaN # but this gives a warning > sin(Inf) [1] NaN Warning message: In sin(Inf) : NaNs produced # and this again does not > exp(NaN) [1] NaN Conceptually, I like to think that R

Hello everyone, one of our customers using QUALCOMM Windows Eudora Version 7.1.0.9 as POP3 client with Dovecot 1.0.0 under Linux using Maildirs reports that on various accounts they get occasional "inconsistent mailbox" errors at quit. The same Docevot binary in the same environment on other servers works fine for several other customers and ourselves. We use Postfix 2.2 with

R and the S language that it is based on has evolved as much as it has been designed, so there are often inconsistencies due similar functionality evolving from different paths. In some cases these inconsistencies are resolved, but generally only once someone notices and care enough to do something about it. In some other cases the inconsistencies are left for historical reasons and for back

...t;: > Hi! > > Please send these to dovecot at dovecot.org instead of us directly. Thank you. Ok, added to cc. > Also, did you try force-resync? Not help. # doveadm force-resync -u altek at altek.info \* doveadm(altek at altek.info): Warning: mdbox /srv/vmail/altek.info/altek/storage: Inconsistency in map index (63,31880 != 63,332136) doveadm(altek at altek.info): Warning: fscking index file /srv/vmail/altek.info/altek/storage/dovecot.map.index doveadm(altek at altek.info): Warning: mdbox /srv/vmail/altek.info/altek/storage: rebuilding indexes doveadm(altek at altek.info): Warning: fscking in...

...g the underlying strtol function >> (see data.table link for this program, and for full >> sessionInfo() of some environments with differing >> output). >> So, what is the correct output of strtoi("", base = 2L)? >> Is the cross-platform inconsistency to be >> expected/documentable? > The inconsistency is certainly undesirable. The relevant > utility function in R's source (<R>/src/main/character.c) > is > static int strtoi(SEXP s, int base) { long int res; char > *endp; > /*...

...yme or reason the connections get dropped, the same set of users who previously were able to access the shares, now get permission denied. Users (not all but some) are having trouble opening the folders, files and so on. This was not the case few days ago, it started happening lately with amazing inconsistency. Inconsistent in it works some times, it simply doesn't sometimes. I have two samba servers in the setup one on Solaris-10 and the other on Solaris-9. On Solaris 10 I'm using stock SUN Samba packages. It would be real easy, if I could isolate the problem by limiting it to one, but i...