On Tue, 30 Apr 2002, Matthew Orgass wrote:

> On Mon, 29 Apr 2002, Bill Studenmund wrote:
> > On Tue, 30 Apr 2002, enami tsugutomo wrote:
> > Is it? I agree that the memcpy code is exactly the memcpy code you'd use
> > for a NUL terminated string. But for example ufs only looks at cn_namelen
> > characters. It copies cn_namelen + 1, but only ever looks at cn_namelen of
> > them. While adding a trailing '\0' might make dumps look nice, I don't
> > think we need it.
>
>   It actually copies what it assumes to be '\0' to the disk, causing fun
> corruption (and a quick panic) if that assumption isn't correct.  I
> actually had trailing slash patches about two years ago but noticed the
> corruption and unfortunately got sidetracked before finding the cause or
> filing a PR.

How? What programs/file systems crashed?

I'm asking as ufs copies the length (which does NOT include the trailing
slash(es)), and uses memcpy() to compare only length worth of bytes. So
the value of that extra byte doesn't matter. NOTHING SEEMS TO BE EXPECTING
THIS TRAILING '\0'.

I'm not saying you didn't see crashes, I'm saying I don't see where they
came from. Directory lookup (VOP_LOOKUP()) seems fine, and readdir
(VOP_READDIR()) seems fine for ufs. What failed?

>   It is also needed for compatibility with systems that allow trailing
> slashes on all files.
>
>   The following patches should now be a complete fix to this problem.
> Trailing slashes are always allowed on Linux and SYSV; I don't know if any
> others need it (ibcs2?).

Well, your patch looks just like mine except you chose a different name,
and made different emulations able to turn it on too. :-)

Take care,

Bill