Enhancement request for the move function

[zeflash]

I've noticed an annoying thing - not really a bug, but bothersome anyway - when moving a file.
It happens only when either the source or target file is in a folder that's actually in a mounted drive (in NTFS).

Copying works fine, I see the progress bar etc.
But, moving files (especially big ones) freezes the interface. I guess the reason is that moving is just supposed to be a TOC change without actually moving data - but in this case it's just like a copy between 2 different drives.

So, as it seems that now you know if a folder is actually a mounted drive or not (I can see that the icon differs), I propose that you handle the move operation in these cases as a copy + delete instead of relying on the windows function that doesn't give any feedback.

Possible, isn't?

Thanks

[ghisler(Author)]

Indeed the problem is the Windows MoveFile function: It copies and deletes the file automatically in this case, but doesn't provide any progress callback or so, so TC cannot show a progress dialog.

[Lefteous]

Is there a way to make use of MoveFileWithProgress?

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base/movefilewithprogress.asp

[ghisler(Author)]

Thanks, this function isn't even in my API help. Ah, it only exists since Win2k, but should be useable via dynamic loading. I will check that.

[integor]

What's the status of this, ghisler? Have you just forgotten it, or have you decided not to fix it? (I'm using Windows XP and Total Commander 6.03a, and still having this problem). I'm getting slightly annoyed by the fact that I can't cancel or background the move between mounted volumes while it is in progress.

[ghisler(Author)]

I haven't tried it yet, because I'm still looking for a fast way to recognize mounted volumes...

[Lefteous]

2ghisler(Author)

I haven't tried it yet, because I'm still looking for a fast way to recognize mounted volumes...

Can you give some more information about the current situation and the wanted behavior?

[integor]

I haven't tried it yet, because I'm still looking for a fast way to recognize mounted volumes...

I suppose the easiest method to check if a file is located on the same volume is to compare the lpszVolumePathName values of GetVolumePathName() for both paths. Since this is done once for every move operation its overhead should be negligible. Allocating a buffer is also quite safe, quoting MSDN "The length of the path returned by this call always is less than or equal to that of the path passed in." (in the case of full pathnames). But if you're a perfectionist, I'm sure there are better ways to do this.

[ghisler(Author)]

GetVolumePathName sounds good, however, it has to be called at least for each subdir copied (the subdir may be a junction), or even for each file (e.g. after feed to listbox). I will check the slowdown for the first case.