This issue's status has been changed to 'Fixed'.

This issue's status has been changed to 'Being worked on'.

I see the example where space is needed, and you want deletes after each individual file test.
BUT, if you are moving a folder that is a software program, with all its DLLs and .INI files, and documentation, then if there is a test failure, you do not want half the program's files on one drive and half on the other, so you want the delete to only occur after ALL tests succeed.
The same applies to a folder that is 10 mp3's that are a CD that you have ripped to your hard drive.  You do not want half the songs on one drive and half on another.
SO, deleting after each individual file should be an option.

Another confirmation on Windows XP...
It shouldn't be yet BETA is better then 'Release' if Test is concerned...
Both Beta and Release have different issues with TeraCopy Move-Test-ing. Release does delete even before confirming as explained here which is totally UNACCEPTABLE. On the other hand Beta does Test-ing after ALL files are copied first then delete after successfull hash matches...
Beta's problem (also present in Release) is space related whereas you'll have to wait "considerable" amount of time if you're needing a space on particular drive and moving files to another drive if you're to move gigs of files and ""time is important""...
IMHO Move-Test should be like this;
a. Get a list of files to move
b. Copy 1. file (Original)
c. Hash Check 1. file's Copy
d. If Hash matches delete 1. file (Original)
e. Repeat steps from b. to d. for the remainder of the files...
This way say if you're to move 20GB of video in 700MB file chunks you won't have to wait the "total" time for copying 20GB + testing then deleting for a free space increase on that drive. Space will increase progressively (without waiting ALL) as each 700MB chunk is copy-test-deleted (move-tested). One may not understand or foresee this before experincing it yet I'd been there and needed this...
In short, Release "should" be rectified for proper Move-Test-ing. And later part is just "feature request"ed for future releases...

The problem is confirmed by user Roby65.

I did another Move and watched even more closely and the same thing happened:
- When the Move part finished and the Test part started, the original folder vanished immediately, so if the Test indicated not a match for a file, then that file would be lost entirely.
I have now reverted back to 2.0 BETA 4 from prior to the nightly builds, until this is fixed, since I cannot afford to lose files entirely.

On December 26th, I asked for a clarification on the deleting.Someone else stated that each individual file was deleted after testing completed.But what I observed today was that the entire folder was deleted prior to testing.Jeff never answered the question about what the behavior was supposed to be, but he did agree to make deleting optional, see the folloiwng interchange:Ken December 28th, 2008 at 23:01 | #16 Reply | Quote Definitely would prefer that it wait until the entire job is completed successfully prior to any deleting.
Generally, the usual job is to move a folder between drives, and having half on one drive and half on the other is certainly worse than having the whole transfer fail.

Jeff December 29th, 2008 at 02:26 | #17 Reply | Quote Agree, will make an option for this. Both methods have their pros and cons.