cvs commit: src/sys/fs/unionfs union_vnops.c

[David Schultz]

On Sat, Jun 14, 2003, Nate Lawson wrote:
> On Sat, 14 Jun 2003, David Schultz wrote:
> >   If someone tries to mount a union filesystem with another unionfs as
> >   the upper layer, fail gracefully instead of panicing.
> >
> >   Revision  Changes    Path
> >   1.99      +14 -4     src/sys/fs/unionfs/union_vnops.c
> >
> > --- src/sys/fs/unionfs/union_vnops.c:1.98	Sat Jun 14 16:27:29 2003
> > +++ src/sys/fs/unionfs/union_vnops.c	Sat Jun 14 16:56:27 2003
> > @@ -670,10 +670,20 @@
> >  	struct vnode *uppervp;
> >  	int error = EOPNOTSUPP;
> >
> > -	if ((uppervp = union_lock_upper(un, cnp->cn_thread)) != NULLVP) {
> > -		error = VOP_WHITEOUT(un->un_uppervp, cnp, ap->a_flags);
> > -		union_unlock_upper(uppervp, cnp->cn_thread);
> > -	}
> > +	switch (ap->a_flags) {
> > +	case LOOKUP:
> > +		error = EOPNOTSUPP;
> > +		break;
> > +	case CREATE:
> > +	case DELETE:
> > +		if ((uppervp=union_lock_upper(un,cnp->cn_thread)) != NULLVP) {
> > +			error = VOP_WHITEOUT(un->un_uppervp, cnp, ap->a_flags);
> > +			union_unlock_upper(uppervp, cnp->cn_thread);
> > +		}
> > +		break;
> > +	default:
> > +		panic("union_whiteout: unknown op");
> > +        }
> >  	return(error);
> >  }
> 
> Is that the default value you want for error?  Perhaps you don't need to
> assign one?

Good eye.  Until five minutes ago, my tree actually said
'error = 0' in the second assignment, but it turns out that
that doesn't quite work.  Since whiteout entries in the upper
layer of a unionfs are special, it's hard to support
externally-visible whiteout entries in the way one would want.
The bottom line is that the assignment at the top of the function
is redundant now, but I don't see a compelling reason to nix it
unless someone else really cares.