I ran into the following bug. The bug occurs when you try to rename a file
and the name of the file is the same except the case is different.

PS C:\> ren hibernate-3.2.0.cr3 hibernate-3.2.0.CR3
Rename-Item : Source and destination path must be different.
At line:1 char:4
+ ren <<<< hibernate-3.2.0.cr3 hibernate-3.2.0.CR3
PS C:\>

Jon

Jon,

I would guess that the product team may consider that "by design".
Since PowerShell is generally case insensitive then, in those terms,
you aren't making a change.

On the other hand, I think you ought to be able to adjust the case of
item.

Have you posted a bug on Connect?

Andrew Watt MVP

On Mon, 10 Jul 2006 15:12:46 -0500, "Jon Miller"
<jemiller@uchicago.edu> wrote:

>I ran into the following bug. The bug occurs when you try to rename a file
>and the name of the file is the same except the case is different.
>
>PS C:\> ren hibernate-3.2.0.cr3 hibernate-3.2.0.CR3
>Rename-Item : Source and destination path must be different.
>At line:1 char:4
>+ ren <<<< hibernate-3.2.0.cr3 hibernate-3.2.0.CR3
>PS C:\>
>
>Jon

I realized that in this case, it's not a file, but, a directory that's being
renamed. I did a couple tests with files and those seemed to work. It also
fails in a simpler case. For example, if you rename a directory named "a" to
"A".

Jon

"Jon Miller" <jemiller@uchicago.edu> wrote in message
news:ubcM0zFpGHA.3584@TK2MSFTNGP03.phx.gbl...
>I ran into the following bug. The bug occurs when you try to rename a file
>and the name of the file is the same except the case is different.
>
> PS C:\> ren hibernate-3.2.0.cr3 hibernate-3.2.0.CR3
> Rename-Item : Source and destination path must be different.
> At line:1 char:4
> + ren <<<< hibernate-3.2.0.cr3 hibernate-3.2.0.CR3
> PS C:\>
>
> Jon
>
>

It works in cmd.exe...

--
greetings
dreeschkind

"Andrew Watt [MVP]" wrote:

> Jon,
>
> I would guess that the product team may consider that "by design".
> Since PowerShell is generally case insensitive then, in those terms,
> you aren't making a change.
>
> On the other hand, I think you ought to be able to adjust the case of
> item.
>
> Have you posted a bug on Connect?
>
> Andrew Watt MVP
>
> On Mon, 10 Jul 2006 15:12:46 -0500, "Jon Miller"
> <jemiller@uchicago.edu> wrote:
>
> >I ran into the following bug. The bug occurs when you try to rename a file
> >and the name of the file is the same except the case is different.
> >
> >PS C:\> ren hibernate-3.2.0.cr3 hibernate-3.2.0.CR3
> >Rename-Item : Source and destination path must be different.
> >At line:1 char:4
> >+ ren <<<< hibernate-3.2.0.cr3 hibernate-3.2.0.CR3
> >PS C:\>
> >
> >Jon
>

This should definitely be bugged. I THINK it is due to some quirks with
foldername API calls versus filename API calls and the fact that you are
technically overwriting the caseless version of the folder name, but I can't
find clear details in the Windows SDK.

The situations I've seen before generally affect files as well as folders,
so I am a little puzzled that it shows up like this, especially
because -Force doesn't work when renaming a folder that differs only in name
case. The usual solution - renaming to something else that varies in
characters, then changing back to the original name recased - works fine in
PS, so here's a "just for kicks" workaround. I do think this can and should
be addressed within PS though; it is probably an issue with FileSystem
PSProvider details rather than with the Rename-Item cmdlet.


function Recase-Folder
{
Param([string]$Path, [string]$NewName, [switch]$PassThru)
$tempName = [System.IO.Path]::GetRandomFileName()
$temp = Rename-Item -Path $path -NewName $tempName -PassThru
$result = Rename-Item -Path $temp -NewName $NewName -PassThru
if($PassThru){$result}
}




"Jon Miller" <jemiller@uchicago.edu> wrote in message
news:OjCuu8FpGHA.2444@TK2MSFTNGP03.phx.gbl...
>I realized that in this case, it's not a file, but, a directory that's
>being renamed. I did a couple tests with files and those seemed to work. It
>also fails in a simpler case. For example, if you rename a directory named
>"a" to "A".
>
> Jon
>
> "Jon Miller" <jemiller@uchicago.edu> wrote in message
> news:ubcM0zFpGHA.3584@TK2MSFTNGP03.phx.gbl...
>>I ran into the following bug. The bug occurs when you try to rename a file
>>and the name of the file is the same except the case is different.
>>
>> PS C:\> ren hibernate-3.2.0.cr3 hibernate-3.2.0.CR3
>> Rename-Item : Source and destination path must be different.
>> At line:1 char:4
>> + ren <<<< hibernate-3.2.0.cr3 hibernate-3.2.0.CR3
>> PS C:\>
>>
>> Jon
>>
>>
>
>

I agree, this should definitely be bugged.
I see no reason for cmd.exe being more powerful than PowerShell.

--
greetings
dreeschkind

"Alex K. Angelopoulos [MVP]" wrote:

> This should definitely be bugged. I THINK it is due to some quirks with
> foldername API calls versus filename API calls and the fact that you are
> technically overwriting the caseless version of the folder name, but I can't
> find clear details in the Windows SDK.
>
> The situations I've seen before generally affect files as well as folders,
> so I am a little puzzled that it shows up like this, especially
> because -Force doesn't work when renaming a folder that differs only in name
> case. The usual solution - renaming to something else that varies in
> characters, then changing back to the original name recased - works fine in
> PS, so here's a "just for kicks" workaround. I do think this can and should
> be addressed within PS though; it is probably an issue with FileSystem
> PSProvider details rather than with the Rename-Item cmdlet.
>
>
> function Recase-Folder
> {
> Param([string]$Path, [string]$NewName, [switch]$PassThru)
> $tempName = [System.IO.Path]::GetRandomFileName()
> $temp = Rename-Item -Path $path -NewName $tempName -PassThru
> $result = Rename-Item -Path $temp -NewName $NewName -PassThru
> if($PassThru){$result}
> }
>
>
>
>
> "Jon Miller" <jemiller@uchicago.edu> wrote in message
> news:OjCuu8FpGHA.2444@TK2MSFTNGP03.phx.gbl...
> >I realized that in this case, it's not a file, but, a directory that's
> >being renamed. I did a couple tests with files and those seemed to work. It
> >also fails in a simpler case. For example, if you rename a directory named
> >"a" to "A".
> >
> > Jon
> >
> > "Jon Miller" <jemiller@uchicago.edu> wrote in message
> > news:ubcM0zFpGHA.3584@TK2MSFTNGP03.phx.gbl...
> >>I ran into the following bug. The bug occurs when you try to rename a file
> >>and the name of the file is the same except the case is different.
> >>
> >> PS C:\> ren hibernate-3.2.0.cr3 hibernate-3.2.0.CR3
> >> Rename-Item : Source and destination path must be different.
> >> At line:1 char:4
> >> + ren <<<< hibernate-3.2.0.cr3 hibernate-3.2.0.CR3
> >> PS C:\>
> >>
> >> Jon
> >>
> >>
> >
> >
>
>
>

I can bug it assuming you don't have to be a beta member or what not. What's
the address? Someone mentioned something about "connect", but, I haven't had
a chance to find out what that is yet...

Jon

"dreeschkind" <dreeschkind@discussions.microsoft.com> wrote in message
news:BBC64E5B-1665-4398-929F-2C4A8D0E3D06@microsoft.com...
>I agree, this should definitely be bugged.
> I see no reason for cmd.exe being more powerful than PowerShell.
>
> --
> greetings
> dreeschkind
>
> "Alex K. Angelopoulos [MVP]" wrote:
>
>> This should definitely be bugged. I THINK it is due to some quirks with
>> foldername API calls versus filename API calls and the fact that you are
>> technically overwriting the caseless version of the folder name, but I
>> can't
>> find clear details in the Windows SDK.
>>
>> The situations I've seen before generally affect files as well as
>> folders,
>> so I am a little puzzled that it shows up like this, especially
>> because -Force doesn't work when renaming a folder that differs only in
>> name
>> case. The usual solution - renaming to something else that varies in
>> characters, then changing back to the original name recased - works fine
>> in
>> PS, so here's a "just for kicks" workaround. I do think this can and
>> should
>> be addressed within PS though; it is probably an issue with FileSystem
>> PSProvider details rather than with the Rename-Item cmdlet.
>>
>>
>> function Recase-Folder
>> {
>> Param([string]$Path, [string]$NewName, [switch]$PassThru)
>> $tempName = [System.IO.Path]::GetRandomFileName()
>> $temp = Rename-Item -Path $path -NewName $tempName -PassThru
>> $result = Rename-Item -Path $temp -NewName $NewName -PassThru
>> if($PassThru){$result}
>> }
>>
>>
>>
>>
>> "Jon Miller" <jemiller@uchicago.edu> wrote in message
>> news:OjCuu8FpGHA.2444@TK2MSFTNGP03.phx.gbl...
>> >I realized that in this case, it's not a file, but, a directory that's
>> >being renamed. I did a couple tests with files and those seemed to work.
>> >It
>> >also fails in a simpler case. For example, if you rename a directory
>> >named
>> >"a" to "A".
>> >
>> > Jon
>> >
>> > "Jon Miller" <jemiller@uchicago.edu> wrote in message
>> > news:ubcM0zFpGHA.3584@TK2MSFTNGP03.phx.gbl...
>> >>I ran into the following bug. The bug occurs when you try to rename a
>> >>file
>> >>and the name of the file is the same except the case is different.
>> >>
>> >> PS C:\> ren hibernate-3.2.0.cr3 hibernate-3.2.0.CR3
>> >> Rename-Item : Source and destination path must be different.
>> >> At line:1 char:4
>> >> + ren <<<< hibernate-3.2.0.cr3 hibernate-3.2.0.CR3
>> >> PS C:\>
>> >>
>> >> Jon
>> >>
>> >>
>> >
>> >
>>
>>
>>

Look for PowerShell on http://connect.microsoft.com
You'll need a Windows Live ID / Passport ID / hotmail.com account to use it.
You can vote for bugs and suggestions in the section called feedback.

--
greetings
dreeschkind

"Jon Miller" wrote:

> I can bug it assuming you don't have to be a beta member or what not. What's
> the address? Someone mentioned something about "connect", but, I haven't had
> a chance to find out what that is yet...
>
> Jon
>
> "dreeschkind" <dreeschkind@discussions.microsoft.com> wrote in message
> news:BBC64E5B-1665-4398-929F-2C4A8D0E3D06@microsoft.com...
> >I agree, this should definitely be bugged.
> > I see no reason for cmd.exe being more powerful than PowerShell.
> >
> > --
> > greetings
> > dreeschkind
> >
> > "Alex K. Angelopoulos [MVP]" wrote:
> >
> >> This should definitely be bugged. I THINK it is due to some quirks with
> >> foldername API calls versus filename API calls and the fact that you are
> >> technically overwriting the caseless version of the folder name, but I
> >> can't
> >> find clear details in the Windows SDK.
> >>
> >> The situations I've seen before generally affect files as well as
> >> folders,
> >> so I am a little puzzled that it shows up like this, especially
> >> because -Force doesn't work when renaming a folder that differs only in
> >> name
> >> case. The usual solution - renaming to something else that varies in
> >> characters, then changing back to the original name recased - works fine
> >> in
> >> PS, so here's a "just for kicks" workaround. I do think this can and
> >> should
> >> be addressed within PS though; it is probably an issue with FileSystem
> >> PSProvider details rather than with the Rename-Item cmdlet.
> >>
> >>
> >> function Recase-Folder
> >> {
> >> Param([string]$Path, [string]$NewName, [switch]$PassThru)
> >> $tempName = [System.IO.Path]::GetRandomFileName()
> >> $temp = Rename-Item -Path $path -NewName $tempName -PassThru
> >> $result = Rename-Item -Path $temp -NewName $NewName -PassThru
> >> if($PassThru){$result}
> >> }
> >>
> >>
> >>
> >>
> >> "Jon Miller" <jemiller@uchicago.edu> wrote in message
> >> news:OjCuu8FpGHA.2444@TK2MSFTNGP03.phx.gbl...
> >> >I realized that in this case, it's not a file, but, a directory that's
> >> >being renamed. I did a couple tests with files and those seemed to work.
> >> >It
> >> >also fails in a simpler case. For example, if you rename a directory
> >> >named
> >> >"a" to "A".
> >> >
> >> > Jon
> >> >
> >> > "Jon Miller" <jemiller@uchicago.edu> wrote in message
> >> > news:ubcM0zFpGHA.3584@TK2MSFTNGP03.phx.gbl...
> >> >>I ran into the following bug. The bug occurs when you try to rename a
> >> >>file
> >> >>and the name of the file is the same except the case is different.
> >> >>
> >> >> PS C:\> ren hibernate-3.2.0.cr3 hibernate-3.2.0.CR3
> >> >> Rename-Item : Source and destination path must be different.
> >> >> At line:1 char:4
> >> >> + ren <<<< hibernate-3.2.0.cr3 hibernate-3.2.0.CR3
> >> >> PS C:\>
> >> >>
> >> >> Jon
> >> >>
> >> >>
> >> >
> >> >
> >>
> >>
> >>
>
>
>

I was just about to agree with you about a bug in the underlying API -
since I'm *SURE* this used to fail in Windows Explorer too and it used
to irritate the hell out of me.

I remember explicitly because I used to have to resort to the "rename
to something else and then rename back to what it should be but with
the correct case" trick that you use below.

BUT, just tried it again in Windows Explorer before posting with my
foot in my mouth and it now seems to work - so maybe there's an
Explorer fix already :-)

BTW, has anyone tried to create a folder in Explorer called ".Net
Framework" :-)

Chris


On Tue, 11 Jul 2006 08:54:35 -0400, "Alex K. Angelopoulos [MVP]"
<aka@online.mvps.org> wrote:

>This should definitely be bugged. I THINK it is due to some quirks with
>foldername API calls versus filename API calls and the fact that you are
>technically overwriting the caseless version of the folder name, but I can't
>find clear details in the Windows SDK.
>
>The situations I've seen before generally affect files as well as folders,
>so I am a little puzzled that it shows up like this, especially
>because -Force doesn't work when renaming a folder that differs only in name
>case. The usual solution - renaming to something else that varies in
>characters, then changing back to the original name recased - works fine in
>PS, so here's a "just for kicks" workaround. I do think this can and should
>be addressed within PS though; it is probably an issue with FileSystem
>PSProvider details rather than with the Rename-Item cmdlet.
>
>
>function Recase-Folder
>{
> Param([string]$Path, [string]$NewName, [switch]$PassThru)
> $tempName = [System.IO.Path]::GetRandomFileName()
> $temp = Rename-Item -Path $path -NewName $tempName -PassThru
> $result = Rename-Item -Path $temp -NewName $NewName -PassThru
> if($PassThru){$result}
>}
>
>
>
>
>"Jon Miller" <jemiller@uchicago.edu> wrote in message
>news:OjCuu8FpGHA.2444@TK2MSFTNGP03.phx.gbl...
>>I realized that in this case, it's not a file, but, a directory that's
>>being renamed. I did a couple tests with files and those seemed to work. It
>>also fails in a simpler case. For example, if you rename a directory named
>>"a" to "A".
>>
>> Jon
>>
>> "Jon Miller" <jemiller@uchicago.edu> wrote in message
>> news:ubcM0zFpGHA.3584@TK2MSFTNGP03.phx.gbl...
>>>I ran into the following bug. The bug occurs when you try to rename a file
>>>and the name of the file is the same except the case is different.
>>>
>>> PS C:\> ren hibernate-3.2.0.cr3 hibernate-3.2.0.CR3
>>> Rename-Item : Source and destination path must be different.
>>> At line:1 char:4
>>> + ren <<<< hibernate-3.2.0.cr3 hibernate-3.2.0.CR3
>>> PS C:\>
>>>
>>> Jon
>>>
>>>
>>
>>
>

On Tue, 11 Jul 2006 07:09:02 -0700, dreeschkind
<dreeschkind@discussions.microsoft.com> wrote:


>I see no reason for cmd.exe being more powerful than PowerShell.

How about:

CMD> rename *.txt *.txt.old

Yeah - I know this has been discussed already, but it's going to take
a while to get used to the arguably reduced function in these specific
cases. Not a complaint you understand (I'm NOT giving it back:-) -
but some things are just different - like the kludges in cmd.exe to
allow "CD\", "CD.." (no spaces) etc