On Tue, 9 Dec 2003, Nick Hodulik wrote: > There is a way. You have to dig down into the code and change "CREATEPROTO" > and "EMPTYPROTO" from mbox to mbx. Assuming your in *nix you'll have to go > to src/osdep/unix/env_unix.c or something similar to do this.
The CREATEPROTO and EMPTYPROTO definitions are in the src/osdep/unix/Makefile. It is meaningless to set EMPTYPROTO to mbx. You can do it, but it won't accomplish anything. It will make empty files unusable. > If you want > mail to live in a subdirectory called "mail" in each users home dir then you > must change src/osdep/unix/Makefile to reflect this as well. Now, that is in env_unix.c. > Which brings me to a question: why can't these options be passed in to > UW-IMAP as compile-time switches? You most certainly can set CREATEPROTO and EMPTYPROTO as compile-time switches. > Every single time there's a new release I > have to delve into the code and change these flags, and I'm sure I'm not the > only one. It would be one thing if they were really esoteric things, but > they aren't: they're very basic, important changes that make UW-IMAP usable > on production servers. How? If you have a shell access system, then by setting the subdirectory you are dictating to your shell users where they store their mail for use by IMAP. If the user runs a client that uses some other name, you've screwed him; you've unilaterally made the decision for *all* users that one, and only one, subdirectory name must be used. If you don't allow shell access to the IMAP server, then may be no real need to put mail in a subdirectory. The whole point of a subdirectory is to separate mail from other files that a user may have. But if it's a dedicated IMAP server, there shouldn't be any files. Of course there are systems which don't neatly fit into either of the above categories. However -- and this point bears emphasizing -- the cost of miscategorizing such a system is merely that the client has to have a "prefix" configured. The cost of making the opposite mistake is a denial of access to mail. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
