From: Herbert Pötzl (herbert_at_13thfloor.at)
Date: Sun 27 Jul 2003 - 22:26:46 BST
Hi Sam!
On Sun, Jul 27, 2003 at 10:04:32PM +0100, Sam Vilain wrote:
> On Wed, 23 Jul 2003 15:34, Herbert Pötzl wrote:
> > ... but this was the moment I asked myself:
> > - do we need the ILI flag at all?
> > - isn't the concept enough for everyday
> > VS usage scenarios?
>
> Absolutely. But a more generic solution may end up solving problems
> that you didn't think of originally.
>
> > what if we apply the following logic:
> > - a file, set to immutable, having a link
> > count of greater than 1, can be removed,
> > but not changed from within a VC, as if
> > the ili flag was set, all other files are
> > just handled as normal ...
> > - on removal of the last but one link, the
> > immutable flag is cleared, and the file
> > becomes a 'normal' file ...
>
> This breaks the normal immutable semantics. On the other hand, this
> would be fine if it was a configurable behaviour.
it could either be limited to the context environment
(as suggested, which would not break the normal semantics)
or enabled/disabled via some capability CAP_IMMUNLINK ...
> You will still need the split immutability macros, so all it saves you
> is one bit per inode. I think really it is just a matter of
> "registering" the bit with the maintainers of the relevant code so
> that no other feature comes and uses it after that.
no, I disagree, it's not about registering this
bit, it's about having to maintain (set/unset) this
bit which requires tool support and filesystem support
which, IMHO is not required at all ...
think about it ...
> Perhaps posing the question to the e2fsprogs mailing list and the LKML
> would help. I did that once a long time ago, maybe this time they
> will listen :-).
if you provide substantial arguments, why we need
this ;-) I will support you on this crusade ...
best,
Herbert
> --
> Sam Vilain, sam_at_vilain.net
>
> My life has no purpose, no direction, no aim, no meaning, and yet I'm
> happy. I can't figure it out. What am I doing right?
> -- Charles M. Schulz
>