Re: help with rename

[Jim Meyering]

Eric Blake wrote:
> 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;

That is definitely the case in question, as seen in the
original tests/mv/trailing-slash.  I don't recall which errno.

> 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?

You're welcome to remove it.
Even back in 2001 when Volker wrote that test, he admitted
that it was getting harder and harder to find systems old
enough to demonstrate the failure.

> 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.