>
> I'd live with that, but I'd prefer just /var/mail be used and if vendors
> want to create a symlink for backward compatibility or even from
> /var/mail to /var/spool for easy upgrades, let them.. (creating a
> symlink from /var/mail to /var/spool/mail if /var/mail does not exist is
> likely h
> Most Mail User Agents for standard Unix systems look in /var/mail/
> for the user's mailbox. So if qmail is switching to ~/Mailbox, then
> they have to solve the problem for all of the various MUA's out there,
> and that is really qmail's and mutt's problem. I assume someone in that
> community
> One simple one - I want my mail on the spool disk. Its in the grows
> randomly, mostly crap, doesnt cause hassle if it fills for a while
> category
That, I believe, is not the majority opinion. At most industrial
sites, mail spool overflow is a major crisis.
> I have no problem with a "both pa
> On Mon, 25 Jan 1999, Theodore Y. Ts'o wrote:
> > If we must back out /var/mail (for no good technical reason that I can
> > determine), then at the very least I think we should state that there
> > that for all compliant distributions, /var/mail *MUST* be a valid way of
> > reaching the spool dir
> >> New systems would need to have a /var/spool/mail -> /var/mail symbolic
> >> link for about two years.
>
> Erik Troan <[EMAIL PROTECTED]> writes:
>
> > No, forever. Red Hat is promising an upgrade path for a lot longer then two
> > years -- we've already provided upgradeable distributions for
> > Please think about it and stay with /var/spool/mail.
Right now, /var/mail and /var/spool/mail both suffer the same problem:
whichever is used, some people need to use the other, hence it is a
*requirement* that both can be used by programs.
Given that, it is better to use /var/mail, because t
> > I agree. I also don't think it's a big deal. What's important is that
> > all of the MUA's get compiled so that they look for the mail spool in
> > /var/mail. If /var/mail is a symlink to /var/spool/mail, or /u3/mail,
> > or something else --- that's fine.
>
> Adding that symlink can be don
> > I would *much* prefer this, I just didn't think I'd be able to win
> > the argument.
>
> Since this is "the objection that won't die", I'm currently
> considering four "ways out" of the mess created by this change that
> went into FHS 2.0.
>
> 1. totally revert, drop /var/mail, and specify /
8 matches
Mail list logo
