Date: Sat, 1 Apr 1995 09:03:14 -0600 (CST) From: Peter da Silva <peter@bonkers.taronga.com> To: taob@gate.sinica.edu.tw (Brian Tao) Cc: terry@cs.weber.edu, freebsd-hackers@freefall.cdrom.com Subject: Re: Mail... Message-ID: <199504011503.JAA01947@bonkers.taronga.com> In-Reply-To: <Pine.BSI.3.91.950401014023.1567A-100000@aries.ibms.sinica.edu.tw> from "Brian Tao" at Apr 1, 95 01:48:09 am
next in thread | previous in thread | raw e-mail | index | archive | help
> Precisely. Since we are all used to seeing hierarchical > filesystems, this model can be applied to a mail spool rather well. > Each individual user's mailbox is represented as a directory > structure, where the "inodes" make up the mailbox index. Each message > is represented as an individual file inside that directory. Nifty. Then you could read it with "mh" directly without doing an "inc". HOWEVER, on the subject of special purpose file systems, let me tell you a story. On the Amiga it was decided to make the environment visible as "env:". Now, the environment was already global (the Amiga was relentlessly single-user) stored as an array off a shared library (the Aztec compiler started this and everyone picked it up). So they were going to make the "env:" device look at this. But for the first cut, they just created an assign (like a VMS logical name) pointing into RAM: called ENV:. This worked so well they just changed the library to point to the ENV: assignment. The moral is, why not just change the mail delivery software to store the mail in this format in the first place? Maybe even in the user's home directory in "Mail/inbox"? I'm not saying going and doing either... just that writing a special purpose file system is kind of a lot of work to go to when the regular file system already does the right thing.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504011503.JAA01947>