Fixed MOVE truncates files

Jul 21, 2012

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. :(

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.
Jul 21, 2012
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.


Staff member
May 14, 2008
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.
Jul 21, 2012
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.