> On 06/03/2023 13:06 EET Tim Evers <te-ml-...@artfiles.de> wrote: > > > Am 06.03.23 um 11:59 schrieb Aki Tuomi: > > >> On 06/03/2023 12:44 EET Tim Evers <te-ml-...@artfiles.de> wrote: > >> > >> > >> Am 06.03.23 um 11:42 schrieb Aki Tuomi: > >> > >>>> On 06/03/2023 12:32 EET Tim Evers <te-ml-...@artfiles.de> wrote: > >>>> > >>>> > >>>> Hi, > >>>> > >>>> since I did not get any feedback on my bug report post regarding > >>>> corrupted sizes while using zlib > >>>> (https://dovecot.org/pipermail/dovecot/2023-February/126105.html) I > >>>> would like to confirm that this bug report reached someone in charge. > >>>> > >>>> Or if not - I would kindly ask for directions on how to post it in a way > >>>> that spawns some action. > >>>> > >>>> Thx > >>>> > >>>> Tim > >>> Can you try erasing dovecot.index.cache and see if the problem fixes > >>> itself? It's possible your cache contains invalid values from old errors. > >>> > >>> Aki > >> Did that already several times (other dovecot.index.* files too). The > >> only thing that helps is actually deleting the dovecot-uidlist file but > >> the problem returns. > >> > >> Tim > > I think it's because the value on the filename is wrong. The filename > > contains the virtual and physical size. > > > > Can you try if > > https://github.com/dovecot/tools/blob/main/maildir-size-fix.pl fixes your > > issue? > > > > Aki > > Quoting > > https://doc.dovecot.org/configuration_manual/zlib_plugin/ : > > "All mails must have ,|S=<size>|in their filename where <size> contains > the original uncompressed mail size, otherwise there will be problems > with quota calculation as well as other potential random failures." > > And the script you send: > > "# Check if the files are compressed. Use the uncompressed size for S=size." > > Which it does in my example. S= contains the uncompressed size, not the > size on disk. Is this not correct? All Files are written exclusively by > dovecot, no other software is involved. > > Tim
Can you send output from `doveconf -n`? I am having suspicion that zlib plugin isn't always involved in your config, which causes the compressed file to be cached wrongly. Especially it feels like your IMAP protocol does not have compression on while LMTP does. Aki
