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/