From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <9ab9f5fd9ed2f70293e8d8f61c1a2167@plan9.escet.urjc.es> To: 9fans@cse.psu.edu Subject: Re: [9fans] permission bit of /mail/box From: Fco.J.Ballesteros In-Reply-To: <018171da47f1d62ed7e0278bf14eb90c@granite.cias.osakafu-u.ac.jp> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-giklgodcnjaumismnlmgdtqudz" Date: Mon, 22 Sep 2003 09:22:54 +0200 Topicbox-Message-UUID: 40958cc8-eacc-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-giklgodcnjaumismnlmgdtqudz Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit The problem is how do you know what's junk and what's not without requiring human intervention. For example, it's nice to have a different not archived fs because users know that all in the main one gets archived; thus there's no opportunity for them to forget to set the noarchive bit. I thought of adding the noarchive bit, to unify our main (archived) and once (not archived) file systems; but after thinking twice, I thought users would forget to set the bit on tars downloaded and the like. Regarding abusing the dump, i.e. student homes, right now their homes here are in a not archived file system. Next semester I'm going to experiment with putting them in a fossil with snap but without archiving. BTW, we're receiving *a*lot* of fake upgrade/patch/download mails pretending to be from MS; i.e. 50M just for me just the last weekend. I resorted to /mail/lib/patters because the spam filter does not seem to be enough by now to stop it. Is the same happening to you? --upas-giklgodcnjaumismnlmgdtqudz Content-Type: message/rfc822 Content-Disposition: inline Received: from mail.cse.psu.edu ([130.203.4.6]) by aquamar; Mon Sep 22 09:13:30 MDT 2003 Received: by mail.cse.psu.edu (CSE Mail Server, from userid 60001) id B32B519C1F; Mon, 22 Sep 2003 03:13:19 -0400 (EDT) Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.4.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id F2D9019C10; Mon, 22 Sep 2003 03:13:15 -0400 (EDT) X-Original-To: 9fans@cse.psu.edu Delivered-To: 9fans@cse.psu.edu Received: by mail.cse.psu.edu (CSE Mail Server, from userid 60001) id 0A31519C15; Mon, 22 Sep 2003 03:12:10 -0400 (EDT) Received: from granite.cias.osakafu-u.ac.jp (granite.cias.osakafu-u.ac.jp [157.16.101.69]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id CB4C519C07 for <9fans@cse.psu.edu>; Mon, 22 Sep 2003 03:12:08 -0400 (EDT) Message-ID: <018171da47f1d62ed7e0278bf14eb90c@granite.cias.osakafu-u.ac.jp> To: 9fans@cse.psu.edu Subject: Re: [9fans] permission bit of /mail/box From: okamoto@granite.cias.osakafu-u.ac.jp In-Reply-To: MIME-Version: 1.0 Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: 9fans@cse.psu.edu List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Mon, 22 Sep 2003 16:12:59 +0900 X-Spam-Status: No, hits=-0.2 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) > I think the noarchive bit would be trivial to implement -- the > necessary code already exists in order to avoid archiving /n/snap. > I'm just not sure it's a good idea. I expected this answer. I think it depends on how we consider what is junk. I believe there are many junks in the real world, and we should be able to judge which is junk or not by ourselves when it is concerned ourselves at least. I'm receiving thousands of junk mails describing MS Custermer etc. I think those are definetly junks and never to go archive. Some students may gather some kinds of pictures in his home directory. Those must not be archived! Kenji --upas-giklgodcnjaumismnlmgdtqudz--