Single file handled as name duplicate in MRT

Post by *ghisler(Author) » 2016-07-29, 10:14 UTC

But what is running in that virtual machine? Linux? Windows? Which version?

Lefteous · Post by *Lefteous » 2016-07-29, 10:18 UTC

It's the system I indicated in the first post. Win7, x64.

Post by *ghisler(Author) » 2016-07-29, 10:29 UTC

Sorry, seems like you misunderstood me. I didn't ask about the system you are running on, but the target. You wrote: "try network folder"

Lefteous · Post by *Lefteous » 2016-07-29, 10:44 UTC

I try to give a complete picture. The host is OX 10.11.6 (OS X Journaled, not case-sensitive) running Parallels. Parallels has a virtual machine running Win 7, x64, NTFS. Paralles offers a virtual network accessible as \\psf.

Post by *ghisler(Author) » 2016-08-02, 10:30 UTC

Maybe it's because OS/X is Unix-based, so case-sensitive?

Lefteous · Post by *Lefteous » 2016-08-02, 10:33 UTC

As I wrote I'm not using a case-sensitive file system as host.

For me the question is why TC detects a conflict when there is definitely only one file in a folder.

Post by *ghisler(Author) » 2016-08-02, 13:22 UTC

It means that the MoveFile call apparently fails - TC only offers this option if
- the MoveFile call fails
and
- the target name exists

TC doesn't even check whether the target and source name are the same because MoveFile should never fail in this case. Maybe you can see in process monitor with which error it fails?

Lefteous · Post by *Lefteous » 2016-08-02, 13:27 UTC

It means that the MoveFile call apparently fails - TC only offers this option if

Just to make sure we are talking about the same thing. I'm _not_ talking about this dialog. The wrong renaming is done fully automatically.
[img]http://fs5.directupload.net/images/160802/38fghnhc.png[/img]

TC doesn't even check whether the target and source name are the same because MoveFile should never fail in this case. Maybe you can see in process monitor with which error it fails?

Will try that!

Lefteous · Post by *Lefteous » 2016-08-02, 20:40 UTC

Here is the log:
http://lefteous.totalcmd.net/tc/bugs/thread_45030_log1.pml

After some research it seems that this is a known problem - whatever causes it.

I also tested it in SpeedCommander where the author works on a Mac with Parallels and it has the same problem when manually renaming.

The question is now what to do. I think it's about how it's handled. While before it silently failed which is at least better than the auto-renaming in this environment.

For me a workaround would be the best solution for the case where ONLY the case is changed. Something like this:

1. User wants to rename Hallo.txt - HALLO.txt
2. TC checks if special INI setting is active and path is not local
3. If this is the case rename Hallo.txt to #______123_temp.txt
4. Rename #______123_temp.txt to HALLO.txt

Post by *ghisler(Author) » 2016-08-03, 16:32 UTC

I have now added some extra code to not append number when renaming files and source+target name are identical, or differ only in case. I have considered to rename via an intermediate name, but this is risky (may overwrite currently hidden files), so maybe later.

Lefteous · Post by *Lefteous » 2016-08-03, 20:30 UTC

I can confirm that in beta 8 the file to rename is displayed bold in the described scenario.

It would be great if a workaround could be implemented as described. I will also contact Parallels and ask them them if they can do something about it.

Post by *ghisler(Author) » 2016-08-05, 10:23 UTC

OK, moving to fixed for now. If Parallels cannot fix it, I will consider to add the workaround.

Lefteous · Post by *Lefteous » 2016-08-10, 21:42 UTC

I contacted the Parallels support. They are currently investigating the issue. They have a very let's say proactive support (actually calling me if they need more information!) so there is some hope they will do something about it.