Subject: Re: Larger rm Change
To: Emmanuel Dreyfus <email@example.com>
From: Andrew Brown <firstname.lastname@example.org>
Date: 01/07/2003 18:41:54
>> personally, i *expect* those flags to make rm fail. in the case that
>> they do so, rm prints an error, and then i can decide if i really
>> meant to remove that file (and remove the flags and try again if i
>> really really meant to remove the file).
>I noticed that, but I think it is okay. I would have been shocked if it
>tried to remove system immutable flags, but this is just about root
>ignoring user immutable flag, this is different.
>Root knows what (s)he is doing. If root decides to blow away some user
>data, I think that there should not be any way for the user to make it
>fail. Think about automatic /tmp cleanup for instance.
if automated /tmp cleanup is your concern, then you should already be
concerned about the mechanism as it stands. it does a quick rm of
stuff that doesn't match a crude pattern and then tries to use find to
finish the job. all i need to do to make stuff "stick" in /tmp is
name a directory lost+found or quota.user or quota.group; i don't need
any flags to do it. the best way to clean tmp is with newfs or mount
an mfs on /tmp. or not care at all about it (which is actually
>User immutable is for the user, so when a user uses rm, it should not
>remove user immutable files. But root should not care about user
>immutable flags. I see only one exception to this rule: I think it is
>bad to make rm remove user immutable flags on files owned by root.
i think we should sstick with the whole hog here.
|-----< "CODE WARRIOR" >-----|
email@example.com * "ah! i see you have the internet
firstname.lastname@example.org (Andrew Brown) that goes *ping*!"
email@example.com * "information is power -- share the wealth."