Re: kern/45425: how to restore traditional unix behaviour for slashes on the end of pathnames

["Greg A. Woods" <woods%planix.com@localhost>]

The following reply was made to PR kern/45425; it has been noted by GNATS.

From: "Greg A. Woods" <woods%planix.com@localhost>
To: NetBSD GNATS <gnats-bugs%NetBSD.org@localhost>
Cc: 
Subject: Re: kern/45425: how to restore traditional unix behaviour for slashes 
on the end of pathnames
Date: Sun, 13 Nov 2011 13:18:46 -0800

 --pgp-sign-Multipart_Sun_Nov_13_13:18:45_2011-1
 Content-Type: text/plain; charset=US-ASCII
 Content-Transfer-Encoding: quoted-printable
 
 At Sun, 13 Nov 2011 17:57:32 +0000, David Holland 
<dholland-bugs%netbsd.org@localhost=
 > wrote:
 Subject: Re: kern/45425: how to restore traditional unix behaviour for slas=
 hes on the end of pathnames
 >=20
 > Of course. But so what? The system's overall behavior should be
 > consistent.
 
 In the context of this discussion the only thing I can imagine you mean
 by that is that, by extension of what you've said, you ultimately think
 the kernel should do pathname globing too.  That doesn't seem like
 something you would actually want though, and it certainly would be a
 far more radical change, so perhaps I'm not really understanding what
 you're trying to say.
 
 If you don't mean that you want globing in the kernel then please keep
 in mind that system calls are a programming interface, not a _user_
 interface.
 
 Depending upon the programs used, the user's experience is going to be
 radically different at the user-interface level than it would be if the
 user were somehow entering system calls directly into the kernel.
 
 There are any number of possible ways to allow the user to express
 groups of filenames, types of filenames, etc.  I.e. anyone can create
 any kind of weird and/or wonderful user interface to the file system on
 top of the existing system call interface.  Whether you click and drag
 with the mouse to sweep over a visual representation of a group of
 files, or whether you type an asterisk to the shell program to select a
 group of files, or whether you do something else completely different,
 depends entirely on what program or set of programs is in between you
 and the kernel and how imaginative the author of that program was.
 
 I believe that by treating slashes in pathnames purely as separators at
 the system call interface, certain aspects of programming using that
 interface, as well as perhaps certain aspects of implementing that
 interface, are all kept simpler (at least at a conceptual level where it
 may be most important to keep things as simple as possible).
 
 >  >  >  and that in turn will break a bunch of
 >  >  >  scripts that do things like "ls -d */ | ...".
 >  > =20
 >  >  I've definitely never seen anything like that.  I would think it was =
 an
 >  >  error if I did see it.
 >=20
 > Perhaps your experience isn't universal...
 
 Perhaps instead of remarking about a claim I clearly did not make, maybe
 you could address the actual issue I raised about your example, even
 though it's not really relevant to the context of this PR (especially
 since, as I demonstrated, my change to restore interpretation of slashes
 only as separators does not affect the behaviour of at least one shell
 implementation in how it executes your example).
 
 
 Unfortunately it appears I made a critical mistake in the process of
 manually copying my change from the netbsd-5 branch to the trunk.  A
 corrected patch follows....
 
 --=20
                                                Greg A. Woods
 
 +1 250 762-7675                                RoboHack 
<woods%robohack.ca@localhost>
 Planix, Inc. <woods%planix.com@localhost>      Secrets of the Weird 
<woods%weird.com@localhost>
 
 
 Index: sys/kern/vfs_lookup.c
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 RCS file: /cvs/master/m-NetBSD/main/src/sys/kern/vfs_lookup.c,v
 retrieving revision 1.192
 diff -u -r1.192 vfs_lookup.c
 --- sys/kern/vfs_lookup.c      27 Sep 2011 02:10:55 -0000      1.192
 +++ sys/kern/vfs_lookup.c      13 Nov 2011 20:43:33 -0000
 @@ -825,9 +825,10 @@
        ndp->ni_pathlen -=3D cnp->cn_namelen;
        ndp->ni_next =3D cp;
        /*
 -       * If this component is followed by a slash, then move the pointer to
 -       * the next component forward, and remember that this component must be
 -       * a directory.
 +       * If this component is followed by one or more slashes then move the
 +       * pointer to the next component forward.  If there is another
 +       * component following the slash(es) then remember that this component
 +       * must be a directory.
         */
        if (*cp =3D=3D '/') {
                do {
 @@ -836,7 +837,8 @@
                state->slashes =3D cp - ndp->ni_next;
                ndp->ni_pathlen -=3D state->slashes;
                ndp->ni_next =3D cp;
 -              cnp->cn_flags |=3D REQUIREDIR;
 +              if (*cp !=3D '\0')
 +                      cnp->cn_flags |=3D REQUIREDIR;
        } else {
                state->slashes =3D 0;
                cnp->cn_flags &=3D ~REQUIREDIR;
 @@ -851,6 +853,7 @@
                else
                        cnp->cn_flags &=3D ~MAKEENTRY;
                cnp->cn_flags |=3D ISLASTCN;
 +              cnp->cn_flags &=3D ~REQUIREDIR;
        } else {
                cnp->cn_flags |=3D MAKEENTRY;
                cnp->cn_flags &=3D ~ISLASTCN;
 @@ -984,9 +987,8 @@
                        goto done;
 =20
                /*
 -               * If this was not the last component, or there were trailing
 -               * slashes, and we are not going to create a directory,
 -               * then the name must exist.
 +               * If this was not the last component, then the name must
 +               * exist (and of course it must be a directory).
                 */
                if ((cnp->cn_flags & (REQUIREDIR | CREATEDIR)) =3D=3D 
REQUIREDIR) {
                        error =3D ENOENT;
 
 --pgp-sign-Multipart_Sun_Nov_13_13:18:45_2011-1
 Content-Type: application/pgp-signature
 Content-Transfer-Encoding: 7bit
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.9 (NetBSD)
 
 iD8DBQBOwDQ1Zn1xt3i/9H8RAuFnAKCMamCQh6g2VHjX22bqZ4AiIEErDwCgydxq
 prfM6sTPSTU3gw8aVZyr8FY=
 =cAhe
 -----END PGP SIGNATURE-----
 
 --pgp-sign-Multipart_Sun_Nov_13_13:18:45_2011-1--