On 18.3.2012, at 23.52, Arkadiusz Miśkiewicz wrote:
>>> "Expunging a message only decreases the message's refcount. The space is
>>> later freed in "purge" step. This is typically done in a nightly cronjob
>>> when there's less disk I/O activity. "
>>>
>>> What happens if there is filesystem hard
On Sunday 18 of March 2012, Timo Sirainen wrote:
> On 18.3.2012, at 23.00, Arkadiusz Miśkiewicz wrote:
> > http://wiki2.dovecot.org/MailboxFormat/dbox
> >
> > "Expunging a message only decreases the message's refcount. The space is
> > later freed in "purge" step. This is typically done in a night
On 18.3.2012, at 23.00, Arkadiusz Miśkiewicz wrote:
> http://wiki2.dovecot.org/MailboxFormat/dbox
>
> "Expunging a message only decreases the message's refcount. The space is
> later
> freed in "purge" step. This is typically done in a nightly cronjob when
> there's less disk I/O activity. "
>
http://wiki2.dovecot.org/MailboxFormat/dbox
"Expunging a message only decreases the message's refcount. The space is later
freed in "purge" step. This is typically done in a nightly cronjob when
there's less disk I/O activity. "
What happens if there is filesystem hard quota that is exceeded?
On 18.3.2012, at 17.36, Charles Marcus wrote:
> On 2012-03-18 11:15 AM, Timo Sirainen wrote:
>> Only time when the entire mbox file is rewritten is when you
>> expunge the first message.
>
> Hmmm... wonder if there would be a way to add some kind of 'dummy' first
> message that dovecot would s
On Sun, Mar 18, 2012 at 11:36:25AM -0400, Charles Marcus wrote:
>
> Hmmm... wonder if there would be a way to add some kind of 'dummy'
> first message that dovecot would simply ignore (not show to the
> user), that would prevent that bevaior?
That's what uw-imap does. It creates a message with th
On 2012-03-18 11:15 AM, Timo Sirainen wrote:
Only time when the entire mbox file is rewritten is when you
expunge the first message.
Hmmm... wonder if there would be a way to add some kind of 'dummy' first
message that dovecot would simply ignore (not show to the user), that
would prevent th
On 2012-03-18 5:16 AM, Stan Hoeppner wrote:
Is your problem with the PST files themselves, or merely the fact
they're stored on the local PC, probably in the users' roaming profiles,
thus creating the problem of large data movement during logon/off?
If so, using redirected folders (if you're n
Timo Sirainen wrote:
> On 18.3.2012, at 0.28, Sven Hartge wrote:
>> mbox has big problems with concurrent writes, the bigger the mbox is,
>> the more problems you get. This is mainly caused by the meta-data of
>> a message (meaning flags, status, etc.) which is stored inside the
>> mbox file itse
On 18.3.2012, at 0.28, Sven Hartge wrote:
> mbox has big problems with concurrent writes, the bigger the mbox is,
> the more problems you get. This is mainly caused by the meta-data of a
> message (meaning flags, status, etc.) which is stored inside the mbox
> file itself. Flagging a message as re
On 03/18/2012 09:16 AM, Stan Hoeppner wrote:
On 3/17/2012 4:24 PM, Kaya Saman wrote:
Long story but we don't have any control over our mail server which is
handled by the parent company abroad and is on MS Exchange.
To use an IMAP storage solution is the only way to get rid of pesky MS
.pst fi
On 3/17/2012 4:24 PM, Kaya Saman wrote:
> Long story but we don't have any control over our mail server which is
> handled by the parent company abroad and is on MS Exchange.
>
> To use an IMAP storage solution is the only way to get rid of pesky MS
> .pst files which have been causing everyone g
12 matches
Mail list logo
