From owner-cvs-sys  Wed Jun 10 07:15:26 1998
Return-Path: <owner-cvs-sys>
Received: (from daemon@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id HAA07058
          for cvs-sys-outgoing; Wed, 10 Jun 1998 07:15:26 -0700 (PDT)
          (envelope-from owner-cvs-sys)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA06524;
          Wed, 10 Jun 1998 07:11:50 -0700 (PDT)
          (envelope-from bde@godzilla.zeta.org.au)
Received: (from bde@localhost)
	by godzilla.zeta.org.au (8.8.7/8.8.7) id AAA24703;
	Thu, 11 Jun 1998 00:11:48 +1000
Date: Thu, 11 Jun 1998 00:11:48 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199806101411.AAA24703@godzilla.zeta.org.au>
To: bde@zeta.org.au, peter@netplex.com.au
Subject: Re: cvs commit: src/sys/msdosfs msdosfs_vnops.c
Cc: cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, cvs-sys@FreeBSD.ORG,
        dt@FreeBSD.ORG
Sender: owner-cvs-sys@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>> Chflags doesn't have so much history beind not returning EOPNOTSUPP, but
>> EOPNOTSUPP is not mentioned in chflags.2 and EINVAL is documented as the
>> error for fchflags() on a socket.
>
>EOPNOTSUPP is what is returned by the "other" BSD's.  I feel that there is 
>a difference between giving a nonsense (invalid) argument, and the flags 
>case where the backing fs can't support the valid request you've made.

For variant fs's, each fs gets to decide which requests are valid, so
there is no difference.  EOPNOTSUPP means that the fs doesn't even know
how to decide.  For flags, all fs's should support null changes (to
whatever default they return in struct stat) so that all utilities
that use chflags() don't have to avoid calling it for null changes.

Bruce