["mv foo/ bar/" -> EISDIR]
> The way to fix this depends on what you consider the proper way for
> mv and namei to behave. Assuming that namei is correct and should
> reject RENAME and DELETE calls with a trailing /,

I am inclined to say it should; foo/ amounts to foo/. in (almost?) all
contexts, so attempting to rename foo/ should behave the way attempting
to rename foo/. does.

> then one has to fix mv to strip these.

This depends on whether you think mv should accept foo/ as a valid
source spec.  IMO it shouldn't, because as described above it amounts
to accepting foo/. as a source spec.  (As for the filename-completion
issue, I would say you should either configure your shell to not tack
on that stray / when completing a directory name, or learn to delete it
when you want to refer to the directory as an entry in another
directory (ie, foo) rather than as an entity containing files (ie, foo/
or foo/. or similar constructions).

The real problem is, rename(2) and (mostly) mv(1) are not really
operations on files or directories; rather, they are operations on
links, ie, directory entries.  Blurring the distinction between the two
is a fertile source of confusion.  And "foo" and "foo/." are entirely
different when it comes to specifying a filesystem link, though they
are the same when following that link to the directory at the end of
it; "foo/" is a peculiar thing which doesn't really specify _any_
filesystem link, and as a source argument to rename(2) I would argue it
should return EINVAL.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B