From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 17 May 2012 12:43:15 -0700 From: David Romano To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20120517194315.GD9038@paravel.rurs.us> References: <20120517160939.GC9038@paravel.rurs.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [9fans] +t and bind (Was Re: Thinkpad T61 Installation Experience) Topicbox-Message-UUID: 92187e9c-ead7-11e9-9d60-3106f5b1d025 erik quanstrom wrote on Thu, May 17, 2012 at 09:26:40AM MST: > as i see it, the argument for +t is that the files remain in the usual > heirarchy. I think I understand. So basically I don't need to worry about which directories or files are bind(1)'d to others under the hierarchy, and the hierarchy persists beyond reboot/restart. I initially thought that the +t problem something that bind(1) could definitely solve, i.e., bind a directory or file within a hierarchy to another filesystem's directory or file. I think Cinap mentioned something about binding each user's /tmp directory to a directory in the "other" filesystem. I suppose that's the double-edged sword with having the dynamic capabilities of bind(1). If the problem is really one of persistence, is there any benefit to having bind optionally record its last bind mapping for a particular path (within each namespace or within each union directory)? Or rather than modify bind(1), just have a separate program that handles it? Would that make the entire process needlessly complex and raise other issues? - David -- David Romano .:. unobe@cpan.org