help with rename

[Eric Blake]

I'm trying to fix rename in order to implement renameat.  So far, I've added 
workarounds for a Solaris 10 bug (rename("file","oops/") succeeded) and a 
Cygwin 1.5 bug (rename("hard1","hard2") reduced the link count of the hard 
linked file, such that when a later action unlinked "hard2", the file "hard1" 
silently disappears), neither of which were covered by the existing rename or 
rename-dest-slash module.

But I'm stuck trying to figure out what bug the rename module was originally 
invented to work around.  The code in rename.m4 is testing for a bug in rename
("dir/","dir2"), and the comments state:

dnl From Volker Borchert.
dnl Determine whether rename works for source file names with a trailing slash.
dnl The rename from SunOS 4.1.1_U1 doesn't.

This is all dated around 2001, but I couldn't find anything via Google 
describing what Volker found broken about the SunOS 4.1.1_U1 version, or why 
removing the trailing slash from a source file would fix a bug.  And in Mar 
2002, commit f90389a769, Jim mentioned that mips-dec-ultrix4.4 also has the 
bug, but again, I couldn't find any evidence of what the bug was.  And I don't 
have access to any machine that old (not that I really want it; they are no 
longer reasonable porting targets).

My problem is that blindly removing the trailing slash on the source argument 
can lead to POSIX compliance bugs.  That is, calling rename("link","new") is 
required to behave differently than rename("link/","new") (the former renames 
the symlink; and the latter depends on whether you strictly obey POSIX and 
rename the directory referred to by link, or mimic Linux and reject attempts to 
manipulate symlinks with a trailing slash, but either way, the symlink "link" 
is unchanged).

So I'm guessing that the bug was related to actual directories, where rename
("dir/","new") failed (with what errno?) while rename("dir","new") succeeded; 
and that the workaround in rename.c dealt with this case while unintentionally 
crippling the symlink case.  If that is the case, I can fix things to the 
desired behavior, by first performing an lstat() on the slash-reduced "dir" to 
make sure it is still a directory rather than a symlink.

Since the old code is only triggered if rename.m4 detected failure on rename
("dir/","new"), and I haven't been able to find any modern platform where that 
fails, should I just drop support for the old SunOS 4.1 workaround?

Meanwhile, I am developing a unit test (currently over 400 lines of code in my 
sandbox) to hammer all the corner cases I could think of with rename, so 
hopefully we are better covered for what workarounds we have to provide for 
various broken platforms.

-- 
Eric Blake