In data venerdì 04 settembre 2009 hai scritto:
> Simone Lazzaris wrote:
> > Well, if I only put mail on the storage via vusaged, and only fetch mail
> > via Maildir++, that means that the usage values will always be seriously
> > wrong, right?
> Ah, you think that vusaged is a delivery agent, or that it needs to know
> about it's delivery agent to determine usage. It is not, and it does not.
> In the most simple form, it's just doing a 'du' on the directory.
No. I'm aware that vusaged is only a usage tracker daemon; my concern is that
I don't see the point of running a daemon which cannot possibly have
information on the usage short of performing "du" on a directory. Directory
that is mounted on a network appliance.
And, frankly, any installation of a significative size is going to have the
storage on a NAS.
> > Removing the fprintf is ok for MY need, but can complicate the life of
> > peoples who *does* want the vusaged to work, but forgot to set in place
> > its configuration file, or have a syntax error in it.
> > So maybe the best thing to do is put in place a configuration option that
> > let the sysadmin choose the usage tracking backend, Maildir++ or vusaged
> Actually, the original problem you reported was that the client_connect
> connect() errors were cluttering up your logs, and that a missing
> vusagec.conf caused the client API to segfault. This had nothing to do
> with syntax errors in a configuration file, which would be reported
> regardless of whether you remove the fprintfs in client_connect.
But my only concern about removing tout court the fprintf is that, in case a
user should want to use vusaged but forgets to put the conf file in place,
[s]he would have an hard time figuring out whats missing. In that case, the
fprintf is useful.
I thought that should be better explicitly tell the program what I want to do,
than let it guess. The defaults should be safe.
> You're writing about concerns about superficial fprintfs in 5.4, a frozen
> version, that's why it makes sense to just comment out the fprintfs. 5.5
> is a *much* different version, which treats the Maildir++ quota checking
> as broken, which it is.
Ok, if the solution is to comment out some annoying fprintf, it'OK for me.
But if the power of the free software is to let people choose, I'll be glad to
choose what is already working for me. So I think that having an option
(compile time, in configuration or whatever) to keep only the Maildir++ method
is the right thing to have.