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, [EMAIL PROTECTED] > > 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 >
