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: David Holland <dholland%NetBSD.org@localhost>
Subject: Re: kern/45425: how to restore traditional unix behaviour for slashes 
on the end of pathnames
Date: Sat, 05 Nov 2011 14:33:03 -0700

 --pgp-sign-Multipart_Sat_Nov__5_14:33:02_2011-1
 Content-Type: text/plain; charset=US-ASCII
 Content-Transfer-Encoding: quoted-printable
 
 At Sat,  5 Nov 2011 17:00:10 +0000 (UTC), David Holland <dholland-bugs@netb=
 sd.org> wrote:
 Subject: Re: kern/45425: how to restore traditional unix behaviour for slas=
 hes on the end of pathnames
 >=20
 >  On Tue, Oct 04, 2011 at 07:55:00PM +0000, Greg A. Woods wrote:
 >  >   Traditional Unix, from at least V5 onwards and right through to
 >  >   the end (V10) and perhaps beyond (plan 9?), always treated
 >  >   slashes (in groups of one or more) in pathnames purely as
 >  >   separators between components, and thus trailing slashes were
 >  >   always effectively ignored (treated as NULs).
 >  >=20
 >  >   At some point BSD changed this interpretation of trailing
 >  >   slashes.  Apparently they forgot that appending "/." was the
 >  >   correct and obvious way to specify that the final component of a
 >  >   pathname must be a directory.
 > =20
 >  That doesn't work for e.g. mkdir.
 
 Of course not!  :-)
 
 mkdir(2) creates a new directory, one that does not yet exist.
 
 Appending the "/." would only specify an existing directory.
 
 Trying to re-create an existing directory again is an error.  :-)
 
 
 >  >   The only change of behaviour this "fix" causes which might
 >  >   trouble some people, but which I find to be a feature for my own
 >  >   use [...]
 > =20
 >  That would drive me crazy, FWIW. And probably not just me. So it's not
 >  exactly neutral.
 
 :-)
 
 I guess you didn't start out by using a traditional Unix.  :-)
 
 I agree though -- some people accustomed only to the BSD semantics may
 notice the difference in such a way that it could be annoying to them.
 
 I don't notice the difference as much the other way, but I think it can
 make a big difference to programs which manipulate pathnames a lot.
 Unfortunately I don't have a good example handy to give.  I don't think
 it's too hard to imagine the effect on algorithms which compose and
 decompose pathnames though when you think of it as suddenly attaching
 special meaning to one or more trailing slashes on a pathname.  Suddenly
 they have meaning where there was none before.  Every other slash though
 remains only as a separator.
 
 I think the big problem here has come when people confuse the way the
 kernel interprets pathnames with the way some applications interpret
 pathnames some of the time, just as you do below.
 
 
 >  Also, to avoid massive confusion you'd have to change globbing so that
 >  "*/" behaves consistently,
 
 I must confess I have never, to the best of my memory, seen such a thing
 attempted.
 
 That's a shell issue anyway, not a kernel/namei issue.  The kernel does
 no globbing.
 
 What do you expect globbing of "*/" to do?  I can guess it means show me
 only directories....
 
 In any case, my change will not, and does not, affect how any shell does
 such globbing.  Anything doing globbing still has to look at st_mode to
 see what kind of file the names in a directory refer to, if it cares.
 
 
 
 >  and that in turn will break a bunch of
 >  scripts that do things like "ls -d */ | ...".
 
 I've definitely never seen anything like that.  I would think it was an
 error if I did see it.
 
 Again though, that's a shell thing, not a kernel thing.
 
 On first glance, without testing, I would expect such a script to only
 work with ksh maybe, though I confess I'm not sure what is intended.
 
 With netbsd /bin/ksh, and with a kernel with my change, I see this:
 
 $ ls -ld /*/
 drwxr-xr-x   2 root  wheel    512 Nov  2 10:35 /altroot/
 drwxr-xr-x   2 root  wheel   1024 Nov  2 10:54 /bin/
 drwxr-xr-x   2 root  wheel    512 Nov  2 10:35 /cdrom/
 drwxr-xr-x   5 root  wheel  36864 Nov  2 13:49 /dev/
 drwxr-xr-x  25 root  wheel   2048 Nov  3 14:06 /etc/
 drwxr-xr-x   2 root  wheel    512 Nov  2 10:35 /floppy/
 drwxr-xr-x   3 root  wheel    512 Nov  2 16:15 /home/
 dr-xr-xr-x   4 root  wheel    512 Nov  5 13:49 /kern/
 drwxr-xr-x   2 root  wheel    512 Nov  2 10:35 /lib/
 drwxr-xr-x   3 root  wheel    512 Nov  2 10:35 /libdata/
 drwxr-xr-x   3 root  wheel    512 Nov  2 10:52 /libexec/
 drwxr-xr-x   2 root  wheel    512 Nov  2 10:35 /mnt/
 dr-xr-xr-x   1 root  wheel    512 Nov  5 13:49 /proc/
 drwxr-xr-x   2 root  wheel   3072 Nov  2 11:04 /rescue/
 drwxr-xr-x   4 root  wheel    512 Nov  2 11:26 /root/
 drwxr-xr-x   2 root  wheel   2560 Nov  2 11:26 /sbin/
 drwxr-xr-x   2 root  wheel    512 Nov  2 10:35 /stand/
 drwxrwxrwt   2 root  wheel    512 Nov  5 04:30 /tmp/
 drwxr-xr-x  14 root  wheel    512 Nov  2 10:35 /usr/
 drwxr-xr-x  22 root  wheel    512 Nov  2 10:35 /var/
 
 Note there are no regular files shown, though several exist.  Is that
 what's supposed to happen?  It seems reasonable I guess.
 
 I would use "find" though, never "ls" plus shell globbing, for what I
 think is intended.  "ls"+"sh" will fail, perhaps badly (i.e. without
 revealing the problem), if the glob pattern expands to more than ARG_MAX
 characters.
 
 Rsync is another program which puts special meaning on the trailing
 slash given on its command line parameters.  It does this as a
 short-hand for something which could equally well be done with other
 command-line options.  However rsync works equally well on both
 traditional Unix and BSD Unix, so traditional namei has no ill effect on
 it.
 
 --=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>
 
 --pgp-sign-Multipart_Sat_Nov__5_14:33:02_2011-1
 Content-Type: application/pgp-signature
 Content-Transfer-Encoding: 7bit
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.9 (NetBSD)
 
 iD8DBQBOtauOZn1xt3i/9H8RAt6FAJwNk8CO1UT2GYpeQ1bxBY5c4yIBcgCg70iZ
 FbytmMn/6CccutZDDtXVWzw=
 =dOj4
 -----END PGP SIGNATURE-----
 
 --pgp-sign-Multipart_Sat_Nov__5_14:33:02_2011-1--