Backup slow and fails if TEMP drive nearly full

On the laptop I’m writing from I use a 20 GB C: drive plus a 40 GB D: drive. Drive C: is almost full (i.e., about 2 GB free) whilst drive D: has about 15 GB free.

Windows’ %TEMP% variable points to

C:\DOKUME~1\username\LOKALE~1\Temp

which is the 8-character name for

C:\Dokumente und Einstellungen\username\Lokale Einstellungen\Temp

Symptom "Backup is SLOW":
When trying to backup a 2 GB USB stick to some backup folder on D:\Backups\, it works but stays a long time in 7-Zip’s DOS window (while actually and unnecessarily copying the compressed 1.5 GB ZIP file from %TEMP% — being a folder on drive C: — to drive D:!).

Symptom "Backup FAILS":
When trying to backup an 8 GB USB stick to some backup folder on D:\Backups\, it works for a while (about 2 GB), then comes up with some error. (Due to the fact that commandline 7-Zip actually compresses all stick data into a temporary file that goes wherever %TEMP% points to, and doesn’t check free space before. Thus it runs into the "Drive C: full" situation.)

Which leads me to suggesting the following:

1. Let Backup check the free disk space on the "real" destination before it commences operation. Maybe only "roughly", since it cannot know the compression factor beforehand. I’d suggest it be enough to put up a warning if the free space is less than the amount of (uncompressed) data to back up. The user could be alerted and continue at own risk.
2. It would be great if commandline backup could somehow be instructed to work like the 7-Zip GUI: Not use %TEMP% but instead create a .tmp file directly on the destination which gets renamed after completion (or deleted on failure).

Implementing both of the above would surely help avoiding wasting time and helpless users (in case the %TEMP% drive is almost full and some error is shown that they cannot interpret).

What do you think?

N.B.: I’m still using the PA.c 1.6.1.0 platform for "real world" use. Maybe this has already been addressed in version 2?