I'm not sure. We probably need to do a little more testing but I'm on
OSX right now and don't have any Win7 system at my disposal. Later
today I can verify what was returned on XP for new
File("abc").equals(new File("ABC")) .
On 4/25/10, Stefan Bodewig <[email protected]> wrote:
> On 2010-04-23, Matt Benson <[email protected]> wrote:
>
>> On Apr 23, 2010, at 3:08 AM, Stefan Bodewig wrote:
>
>>> 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).
>
>> 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.
>
> OK, you mean in a situation where the file is called "abc" on the disk
> and we reach it via new File("ABC") then we don't want to rename it to
> "abc" (because that already is the name on disk).
>
> Given that new File("abc").equals(new File("ABC")) on Win7 now we
> probably better modify the test to compare the file names directly
> rather than the File objects.
>
> Am I getting this right?
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
