[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
help with rename
From: |
Eric Blake |
Subject: |
help with rename |
Date: |
Wed, 30 Sep 2009 21:25:50 +0000 (UTC) |
User-agent: |
Loom/3.14 (http://gmane.org/) |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- help with rename,
Eric Blake <=