Extremely irritating bug in latest version of Truecrypt (6.2a)

But seeing as their forums will still not allow me any way of contacting them without providing my personal details, this is the only place I can post about it; I'd be grateful if someone here with a working account over at TC forums could voice my problem over there for me.

The problem is that it now seems to be effectively impossible to create hidden volumes through "direct mode". I was able to successfully create a 500GB outer volume, and fill it to just over half (300GB), but when I attempted to create a hidden volume in that same container through TC's "direct mode", it informed me that the maximum size of my volume would be limited to 400 megabytes, even though it clearly showed more than 200GB free. Wondering why this was, I reformatted the volume again to FAT32, this time with a cluster size of 64KB, and refilled it - same problem. I then defragmented the volume and ascertained that there was at least 200GB of contiguous freespace at the end before re-attempting the hidden volume creation wizard, only to be greeted with exactly the same maximum size value. I figured something in the freespace might be causing the problem, so filled it with a single pass of pseudorandom data - still no luck. running out of options, I zeroed the freespace of the volume and tried one last time, again with the same result.

In the absence of any other plausible explanation, I'm forced to conclude that a bug in the (latest version of the) Truecrypt software itself somehow prevents it from being able to see the amount of freespace at the end of a volume in "direct mode", and so makes the whole feature pretty much useless. I haven't used Truecrypt for a couple of years (v4.3, I think, and I certainly didn't have that problem then), so I'm not sure how long this bug has existed for, though I'm guessing it's fairly recent or I'd have read more about it by now.

Was anyone else aware of this, and is there any way around it or another piece of software I could use that wouldn't have this problem? Better still, could someone identify the section of code in the source that causes this problem and release an unofficial fix for it?

 

this is an implementation artifact, though the extreme bias towards small nested/hidden volumes does provide some protection.

in short, hidden volumes are not (for any motivated attacker, solid state hdd, many other factors).

loop-aes+xfs == king.
(roll your own key management, how else to trust?)

best regards,

 

Could you be more precise? I can't think (off-hand) what in the implementation of hidden volumes could be causing this or why anything should have changed at all since version 4.x. Could you point me to the portions of the source that deal with this (perhaps with some additional annotations, given that TC's source code is notoriously poorly documented, and I somehow doubt that's changed since 4.3).