Fixed MOVE truncates files

[Gilad Raz]

Hi,

Reproduction steps:
1. Disk space < file size
2. directory name length > 240 chars
3. move file from within that directory to upper level

Results in "There is not enough space on the disk.", after trying taking a long time - seemingly trying to copy then delete the file, and failing with the copy.

4. Press Ctrl-C in the middle of the MOVE

Results in truncated file at the destination, and deleted source file!

Scary - happened to me some times in the past where I got truncated files after moving them, and I started to mistrust TCC reliability. Now I know why - must have pressed Ctrl-C sometimes in the middle of a move. :(

Thanks,
Gilad

 

[Steve Fabian]

I never observed such an event. Please tell us the OS and TCC version. Another point: is either the source or target directory a symbolic link? Using Vista or later Windows version it is possible for the "upper level" to be on a different volume than the source file, in which case the move could not be performed as a "rename" and would fail, though I agree the observed sequence ought not to delete the source.

 

[Gilad Raz]

TCC 14.01.33 x64 Windows 7 [Version 6.1.7601]

Actually, (1) is not relevant. Also, make sure file size is 500Mb+ so the move slowliness will be more evident. File path length (maybe including file name) must be above 255.
No symbolic links, all on the same (SSD) drive C.

 

[rconn]

This is a Windows API issue, not TCC. TCC is just requesting a rename (assuming you're not using the recycle bin option); it never tries to delete the file unless it's doing a MOVE between different drives. (And then only if the Windows copy file API succeeded.)

It's been there for years; I reported this bug to Microsoft at least 4-5 years ago but they've shown no interest in fixing it. And since it's all happening inside a single Windows API call, there isn't anything that I can do in TCC to fix it.

 

[Gilad Raz]

Recycle bin (/k) or not, both misbehave.
How come REN works fine?

 

[Gilad Raz]

Another relevant bug, but too negligible to be reported on its own thread: Auto-complete a directory with 248+ characters automatically prepends it with "\\?\", which makes the result in a mismatch with the directory name.

 

[rconn]

Another relevant bug, but too negligible to be reported on its own thread: Auto-complete a directory with 248+ characters automatically prepends it with "\\?\"

WAD - it's a feature, not a bug. (A number of the Windows APIs will fail with a filename >= 248 characters, unless it uses the \\?\ prefix.)

 

[rconn]

How come REN works fine?

It uses a different API.

 

[rconn]

Fixed in build 43 (I gave up on Microsoft and replaced their API with my own code).

 

[Gilad Raz]

Hurray!! Thanks :)