On Wed, Jun 03, 2009 at 11:15:31AM -0500, Tom Haynes wrote: > Mike Mackovitch wrote: >> Perhaps there should be a: >> >> if (dvp->v_flag & V_XATTRDIR) >> set_fh4_flag(&fh, FH4_NAMEDATTR); >> >> after the makefh4()? > > Did you download the source, compile, and test?
Nope, sorry... just browsed. > I understand there is at least one person in your group who should still > remember how to do all of that. :-> Heh... probably. But I'm not desparate enough to get this fixed that I'm figuring out how to compile my own kernels. My client code will need to work with this fixed or not. I can help test the fix though. In the meantime, I discovered what seems to be another strange issue resulting from this bug: GETATTR ops don't return the right file type (NF4REG instead of NF4NAMEDATTR) when the "bad" file handle is used. I'm guessing this is because the type is derived from the current file handle stored in the compound_state which is missing the FH4_NAMEDATTR flag in the bad file handles passed back from the client. On Wed, Jun 03, 2009 at 12:27:07PM -0500, Tom Haynes wrote: > Tom Haynes wrote: >> >> In the meantime, I'll open a bug for tracking. >> > > 6847686 NFSv4 named attribute file handle bug > > You'll be able to track this as > http://bugs.opensolaris.org/view_bug.do?bug_id=6847686 > once it gets updated there... Cool! Thanks --macko
