Hi all,

I know this has been discussed before and I don't want to stir up a
flame fest, however NetBSD is getting a bit lonely in its refusal to
accept a trailing '/' on a path supplied to mkdir(2).

  4922 a3       CALL  mkdir(0x804a580,0x1ff)
  4922 a3       NAMI  "fubar/"
  4922 a3       RET   mkdir -1 errno 2 No such file or directory

I recall from previous discussions that NetBSD's behaviour of
returning ENOENT is acceptable per the relevant standards, and we have
a similar restriction on the target path (but not the source path) for
rename(2).

A problem arises that because other platforms permit the trailing '/'
application portability is reduced.  At least FreeBSD, HP-UX, and
Linux allow the traling '/'.

While application portability is the reason that I ask that the
behaviour be changed, there are some arguments on consistency
grounds that mkdir(2) should accept a trailing '/' too:

1. mkdir(1) accepts a trailing '/'

  $ mkdir fubar/ && /bin/ls -ld fubar/
  drwxr-xr-x  2 giles  wheel  512 Jun 23 11:53 fubar/

2. rmdir(2) accepts a trailing '/'

  4922 a3       CALL  mkdir(0x804a587,0x1ff)
  4922 a3       NAMI  "fubar"
  4922 a3       RET   mkdir 0
  4922 a3       CALL  rmdir(0x804a580)
  4922 a3       NAMI  "fubar/"
  4922 a3       RET   rmdir 0

Finally, I notice that there was mention in the last few days of the
need to handle trailing slashes for Linux binary emulation. FreeBSD
binary emulation must need this too?

The only reasons I can think of for keeping the current behaviour:

(a) it's always been that way
(b) it's more efficient

Note that I'm not able to offer a patch: since I have current access
to those billions of dollars worth of SysV source that SCO is suing
IBM about discretion is the better part of valour. :-)

Regards,

Giles

--
Giles Lean <giles@nemeton.com.au>