On Thu, Apr 24, 2003 at 10:34:18PM +0100, Jamie Lokier wrote:
> That would be most reliable, and you want to do that in case the
> filesystem is NFS, too. (On the other hand, there are filesystems
> that support rename(2) but not link(2)).
>
> However rename(2) should not successfully rename from the _old_ path
> more than once, whether the new names are all the same or not.
It shouldn't, but it's a known problem with 2.2. Unfixable without
massive change of locking scheme.
What happens is that "from" lookup of second rename() succeeds
before the first one is over. As the result, you get an old
dentry of "a", _then_ second lookup gives you the same dentry -
renamed to "b" by then. Then you get rename() done with
old and new dentries being identical. Which is required to
return 0 and do nothing.
It's b0rken and 2.3/2.4/2.5 prevent that crap from happening by
saner locking rules (we keep the parent director{y,ies} locked
across the entire "do lookups for last components and proceed
with actual rename" sequence; see Documentation/filesystem/ for
more details).
2.2 is hopeless in that respect - to fix that nest of races we would
need to replace the locking of directories in namei.c and friends.
I doubt that Alan is happy with that idea...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Apr 30 2003 - 22:00:18 EST