I've seen this behaviour with a previous 3.39.xx beta, but cannot say when it started, since I've only now done some testing.
Tested for this behaviour with IE8 and Firefox 3.5; Sandboxie v3.39.17.
Basically, when 'FileRootPath=' is used to specify the sandbox on my TrueCrypt volume, a manual Quick Recovery command (while the browser is still running) does not show all of the downloaded files.
Then, after closing the browser, all of the downloaded files will now be shown in QR's window.
After clicking 'Recover to Same Folder': all of the files are successfully recovered, but the QR window does not close (the files remain listed).

This behaviour does not occur if the default C:\Sandbox\(User) folder is used, instead.
------
I created a new "TrueCrypt2" sandbox, then added the following lines to the settings:
[TrueCrypt2]

FileRootPath=K:\Sandbox\%SANDBOX%
RecoverFolder=C:\Downloads
AutoDelete=y

[Edit] Deleted the line:
AutoRecover=y
[/Edit]
------
Set Firefox to save downloads to C:\Downloads.
Use a sandboxed Firefox to download 3 or more files.
While Firefox is still running, select Quick Recovery from the tray icon.
Only 1 or 2 downloads are ever listed in QR's window (only 1 is shown here):

------
Use Windows Explorer to see all of the downloaded files (3 in this case).

------
Close Firefox, and the Quick Recovery window now shows all 3 downloaded files, not just the first one or two.

------
Click on 'Recover to Same Folder'.
The files are all recovered, but the QR window doesn't change: except that the "Downloads" folder highlighting looks darker.

------
If you click the 'Delete Sandbox' button: the QR window does close, and the sandbox is deleted.

I'm unable to reproduce the problem.
I mounted a TrueCrypt volume X, set the FileRootPath X:\SANDBOX\%SANDBOX%, but Quick Recovery works as expected.
Any ideas?

I'll have to think about it. I did everything that I could think of, before reporting this:
Changing the Recovery Folder location from K: drive to C:; moving the Firefox profile folder from K: to C:; using a newly created sandbox.
None of those made any difference.
I guess I could try creating a new TrueCrypt volume (X: ) and use the default Firefox profile - and see what happens then.
Thanks for checking. If I find out anything that's relevant, I'll report back.

I was using a FAT TrueCrypt volume, how about you?

FAT here, also.
One possibility that I'm just starting to look at is the location of the file for my TrueCrypt volume.
It's mounted as drive K:, but the file is actually located on my Z: drive - a hard drive that's plugged into my router, and accessed via the router's Ethernet connection.
I've created an FAT TrueCrypt volume on C:, and have just started testing, using that volume.

Nothing new to report,as yet.
Using a file on C: for my FAT formatted TrueCrypt volume X:, didn't change anything for me.
Manually opened Quick Recovery windows still stop listing downloads, usually after 3 or more downloads have been made.
QR's window shows all downloaded files after closing Fx, but the files remain listed in QR's window after the (successful) recovery.
Delete Sandbox works as expected.

I'm going to see if I can find a previous beta version that doesn't give me this behaviour, and then work my way through to the newer versions.

[Edit]Well, I've officially given up trying old beta versions (going back to 3.39.03) since I'm even getting the same behaviour with v3.38.
I guess that I have a problem that's unique to me.
Maybe a clean install of Sandboxie will do something.

[Edit 2]I'm not going to bump this thread, since there's nothing really new.
I forced Sandboxie to create a new configuration file, added the TrueCrypt2 sandbox, and tried it with different Firefox profiles.
A clean install of v3.39.18 has resulted in my now being able to see the InfoTip message that desktop.ini contains - I didn't see it before.
However, when downloading into a TrueCrypt volume on C:, mounted as X:, I soon get to the point where I don't see any more files added to the list - in a manually opened Quick Recovery window. The final Recovery of the files is successful, but the QR window still lists the files.
Since this is not my usual sandbox in which to download files, and I'm out of ideas, I guess I'll put this on hold.

How about if you click Reload Configuration when you see the QR is not behaving correctly. Does it fix the problem? If not, try to stop/restart Sandboxie Control -- does that fix the problem?

Yes, either using 'Reload Configuration', or stopping/starting Control, does result in all downloaded files being shown in a manually opened QR window.
If I then make additional downloads, I need to Reload Configuration in order to have them shown in the QR list.
----
The behaviour of having the files still listed in QR's window, after successfully recovering them, remains.
After the final download, and using 'Reload Configuration' to make sure that all files are listed in QR's window, these are the results of trying 3 procedures:
1 - After exiting the browser: click "Close" in QR's window; then run QR and 'Recover to Same Folder': same results, the files are recovered but stay listed in QR's window.

2 - After exiting the browser: click "Close" in QR's window; 'Reload Configuration'; run QR: same results.

3 - Exit Control first; exit the browser; start Control; run QR and all downloads show in the window; click 'Recover to Same Folder': the files remain listed in the window after recovery. Then click 'Close' in QR's window; run QR again; the files are still listed. Click 'Close' in QR's window; 'Reload Configuration'; run QR: the files are no longer listed in the QR window.

So: if the files remain listed in QR after a recovery, it seems that if I 'Close' the QR window and 'Reload Configuration', then the files will no longer be listed when QR is run again.

Ah, then I think I might know what's wrong.

Sandboxie Control caches the timestamp on directories/folders in order to avoid unnecessary re-reads. What probably happens in your case is that even though the directory contents change (files added when downloaded, and deleted when recovered), the timestamp of the directory itself does not change, for some reason. When you Reload Cofiguration it forces Sandboxie Control to re-read the directories.

To confirm this theory, you can use the "DIR /T:W" command on the folder containing your downloads folder, for example:

DIR /T:W X:\SANDBOX\TRUECRYPT2\DRIVE\C

You should see "Downloads" listed in the directory output, and the time/date shown will be its last write time, because of the /T:W option. Then modify the Downloads folder in that sandbox, and issue the command above again. Does the last write time change? For me, in my TrueCrypt volume, it does change.

Your theory is correct.
Here's an edited output from the "dir /t:w x:\sandbox\truecrypt2\drive\c" command:
Before:
Directory of x:\sandbox\truecrypt2\drive\c
09/20/2009 01:46 PM <DIR> .
09/20/2009 01:46 PM <DIR> Downloads
-------------------------------------------------------------
After 4 downloads:
Directory of x:\sandbox\truecrypt2\drive\c
09/20/2009 01:46 PM <DIR> .
09/20/2009 01:46 PM <DIR> Downloads

I downloaded 4 files and the DIR output didn't change.
20 minutes later I downloaded another file, and still the DIR output stayed the same as above.
Now I'm wondering why my TrueCrypt folder Date/Time doesn't change, but yours does.

There's a Preference in TrueCrypt:
"Preserve Time Stamps of File Containers"
that was checked.
I guess that it only applies to the outer "Container" file though, since unchecking it does nothing for the sub-folders that are created inside of the volume.

I said earlier I was testing with a FAT filesystem. That was a mistake, it's actually an NTFS filesystem. I'm pretty sure the change in behavior is due to the different filesystems. I think I remember that FAT does not update directory last write time, whether hosted in a TrueCrpypt volume or not. Sorry for sending you on a wild goose chase trying to figure out which setting might affect this behavior.

Anyway, what I'm going to do is force re-read of the QR folders when the Quick Recovery screen is invoked, that should take care of this problem.

Thanks. I confirmed that a TrueCrypt volume, formatted as NTFS, updates the Time stamp on the Downloads folder as files are saved there.
And we know that a TC volume formatted with FAT does not.

Please check if fixed in version 3.39.19.

Yes, the behaviour that I reported with an FAT formatted TrueCrypt volume has been corrected.
Thanks.