xfs
[Top] [All Lists]

Re: Chattr

To: linux-xfs@xxxxxxxxxxx
Subject: Re: Chattr
From: Ethan Benson <erbenson@xxxxxxxxxx>
Date: Tue, 30 Apr 2002 14:27:39 -0800
In-reply-to: <1020178382.24279.31.camel@jen.americas.sgi.com>; from lord@sgi.com on Tue, Apr 30, 2002 at 09:53:02AM -0500
Mail-copies-to: nobody
Mail-followup-to: linux-xfs@xxxxxxxxxxx
References: <1020111402.18036.0.camel@UberGeek> <1020174674.24262.0.camel@jen.americas.sgi.com> <20020430062608.M21791@plato.local.lan> <1020178382.24279.31.camel@jen.americas.sgi.com>
Sender: owner-linux-xfs@xxxxxxxxxxx
User-agent: Mutt/1.2.5i
On Tue, Apr 30, 2002 at 09:53:02AM -0500, Steve Lord wrote:
> On Tue, 2002-04-30 at 09:26, Ethan Benson wrote:
> > On Tue, Apr 30, 2002 at 08:51:14AM -0500, Steve Lord wrote:
> > > On Mon, 2002-04-29 at 15:16, Austin Gonyou wrote:
> > > > I know you guys are gonna shoot the hell outta me for this, but what can
> > > > one do to set files immutable, as in chattr -i, with XFS? TIA
> > > > -- 
> > > 
> > > Sorry, no can do, XFS does not have an immutable inode concept. All
> > > you can do is close the permissions down on the inode.
> > 
> > which doesn't work since 1) root is immune to permissions and 2) there
> > is no append-only permission bit.
> > 
> > as i understand it there are some unused bits left in the XFS inode,
> > so adding these is possible (and if current implementations set these
> > to zero on create and ignore and leave alone on modify the change
> > would be fully backward compatible (other then older implementations
> > ignoring them)).
> 
> I said you cannot do it, I was referring to the existing code, yes it
> is possible, but currently only ext2 and ext3 support this, and chattr
> is an ext2 utility, not a generic linux filesystem utility.
> 
> Adding it also introduces an on disk incompatibility between Irix and
> Linux, and probably we could not take the code back to Irix, given its
> origin. So we would need to version the superblock - we would need that
> anyway for backward compatibility. All in all it gets to be a larger
> project than you might think. My problem now is definitely not lack of
> work ;-)

why do you necessarily have to version the superblock? do current
implemementations blow up if the existing reserved inodes are
anything but zero?

-- 
Ethan Benson
http://www.alaska.net/~erbenson/

Attachment: pgpxw5ll9m6Pg.pgp
Description: PGP signature

<Prev in Thread] Current Thread [Next in Thread>