> > First, please check whether the scenario you are trying does or doesn't
> > exhibit the same bug in a vanilla system without your changes.
>
> The exact same error.
Well, you certainly could have saved some wild goose chases by making that
clear in the first place.
> It is blocked in the c
> Ok, ch* on the root node changes all of the nodes and a ch* on any of
> the leaf nodes returns EROFS. Reasonable?
Sounds ok to me.
> I started exploring it about two weeks ago; it is well written (wrt
> being os-independent). Thus, I imagine that we could use that.
I am in favor of using (a
On Sat, Jan 20, 2001 at 05:44:13PM -0500, Roland McGrath wrote:
> This is pretty confusing to me, but it's hard to see much without being
> able to debug it myself.
>
> First, please check whether the scenario you are trying does or doesn't
> exhibit the same bug in a vanilla system without your
> > What do you recommend happen when one does a chown part/1? How about
> > a chown part? Should they effect the entire tree?
>
> Eh, whatever. I think it would be ok for these to fail with EOPNOTSUPP.
> Changing the root node would be ok too, but probably surprising to someone
> who thought
> > * netfs_check_open_permissions ought to do an fshelp_access check.
> > In fact, you ought to make it refuse if O_READ or O_WRITE is set;
> > then it will be impossible to reach the netfs_attempt_{read,write}
> > hooks and you can make those call abort or use assert.
>
> What error shoul
>
>
> Now, some comments about the small behaviors of the filesystem hooks.
>
> * netfs_check_open_permissions ought to do an fshelp_access check.
> In fact, you ought to make it refuse if O_READ or O_WRITE is set;
> then it will be impossible to reach the netfs_attempt_{read,write}
> hoo
