On Apr 23, 2010, at 3:08 AM, Stefan Bodewig wrote:
On 2010-04-22, Stefan Bodewig <bode...@apache.org> wrote:
On 2010-04-21, Steve Loughran <ste...@apache.org> wrote:
So perhaps the check for windows (and special handling) is failing
I'll try to fix it.
There is no Windows specific code, I've reopened bug 41948 because its
fix doesn't seem to work reliably on Windows7 anymore.
The problem is this code in Move#renameFile
sourceFile = getFileUtils().normalize
(sourceFile.getAbsolutePath()).getCanonicalFile();
destFile = getFileUtils().normalize
(destFile.getAbsolutePath());
if (destFile.equals(sourceFile)) {
//no point in renaming a file to its own canonical
version...
log("Rename of " + sourceFile + " to " + destFile
+ " is a no-op.", Project.MSG_VERBOSE);
return true;
}
Using Win7 destFile.equals(sourceFile) returns true so no attempt is
even made to rename "abc" to "aBc". Using WinXP it must have returned
false (can't test it anymore).
I would understand why we wanted to skip the rename operation if
the old
and new absolute and normalized file names were the same, but I don't
understand how and why we are comparing one canonical file to a
non-canonical one and then decide we don't need a rename if they
are the
same.
Matt, Martijn or Antoine, you've been involved in fixing the bug many
moons ago - do you still remember why the condition has been written
that way?
IIRC the purpose is to detect the attempted rename of a file to its
own canonical name, e.g. when the original name case-insensitively
equals the target name on a case-insensitive filesystem.
-Matt
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
