From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Masover Subject: Re: reiser4 plugins Date: Wed, 06 Jul 2005 08:18:59 -0500 Message-ID: <42CBDA43.6030305@slaphack.com> References: <200507060255.j662tndQ005308@laptop11.inf.utfsm.cl> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: list-help: list-unsubscribe: list-post: Errors-To: flx@namesys.com In-Reply-To: <200507060255.j662tndQ005308@laptop11.inf.utfsm.cl> List-Id: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: Horst von Brand Cc: Hans Reiser , Hubert Chan , Ross Biro , Kyle Moffett , Valdis.Kletnieks@vt.edu, Lincoln Dale , Gregory Maxwell , Jeff Garzik , Christoph Hellwig , Andrew Morton , linux-kernel@vger.kernel.org, ReiserFS List Horst von Brand wrote: > David Masover wrote: > > [...] > > >>Just don't allow user-created hardlinks inside either metafs (/meta) or >>the magical meta directory inside files. > > > And what is it useful for, after its advantage was that it was /exactly/ > like regular files &c, and now it is severely crippled? The advantage was never that meta files look exactly like regular files, but that they look enough like regular files that you can use existing tools on them. Of course, there are some times when you want meta files to look exactly like regular files, as in (I hate to bring it up again, but...) zip files. So, a zip file (/meta/vfs/some/zip/file/.../contents/) would allow hardlinks between files inside the zipfile, but not outside of it. This would be like creating a separate mountpoint for the zipfile's contents, and doing "mount --bind" when a hardlink to the zipfile is created. I'm not sure if we actually have to pretend it's a mountpoint, or if we can just take the checking that mountpoints already do and generalize it. Can you think of a way in which hardlinks are useful in /meta, in a *general* way, instead of within a specific directory controlled by a specific plugin?