In article <Pine.NEB.4.21.0005021545481.11862-100000@skullport.z.zembu.com>,
Bill Studenmund <wrstuden@zembu.com> wrote:
> On Tue, 2 May 2000, Jaromir Dolecek wrote:
> 
> > Hi,
> > according to chflags(2):
> > 
> > """
> >      The SF_ARCHIVED, SF_IMMUTABLE, and SF_APPEND flags may only be set or un-
> >      set by the super-user.  Attempts by the non-super-user to set the super-
> >      user only flags are silently ignored.  
> > """
> > 
> > At least ffs returns EPERM if user attempts to set super-user settable
> > flags (see ffs_vnops.c: 367-372). Who is right here ? Shouldn't
> 
> Note, that's ufs_vnops.c :-)
> 
> > ffs just return 0 in that case instead of EPERM ? SUS doesn't
> > mention chflags(2) at all.
> > 
> > This inconsistency is the cause of bin/9990 & bin/8439 (msdosfs
> > sets flag SF_ARCHIVED in msdosfs_setattr()/getattr() and this
> > is causing problems if moving "archived" files/directories).
> 
> cvs annotate is your friend. From looking at it, I see that the returning
> of an error was added in revision 1.24 by mikel in response to PR 3491,
> where the submitter suggested chflags should return EPERM if you try to
> set a flag you shouldn't. The PR's you mention indicate why chflags didn't
> do things that way.
> 
> I suggest fixing ufs_vnops.c as you suggest - silently return no
> error. Either that or change the docs, and make mv not complain if it
> can't set the attributes. But the latter's a bit bad as different file
> systems might have different policies about SF_ARCHIVED...
> 

I would prefer to fix the userland programs and the documentation.
I don't like the silently fail syscalls.

christos