@Drugwash: the problem is what M$ calls a "cosmetic issue" in that the CDFS driver works otherwise correctly, but does report the wrong size when asked. It may require a considerable amount of reverse engeneering to pinpoint and correct. Then again, with some luck, it may yield to a simple patch. I really don't know, but I'll investigate it more closely as soon as I can.
Indeed it appears as cosmetic, however certain applications may use the reported size in their own reports, thus creating confusion. For example, a simple disk catalogue software (SuperCat) will display the size of all CDFS DVDs as 2GB, which may lead someone into thinking they may be partly burned (open session) or corrupt. May also mislead regarding the required free destination space when copying from such DVD to another support.Thank you for looking into the issue.
I have looked deeper into the problem and, although I have not yet any solution at this point in time, I believe I have, at least, a good explanation of what's happening:
I)Windows Explorer, Total Commander, SuperCat, Karen's Drive Info and the superb and simple Karl E. Peterson's DriveInfo, along with every other well behaved Windows program, when trying to determine disk capacity, used and free disk space, first check whether the GetDiskFreeSpaceEX API call is available, and if so, call it to get the desired info, but fall back to the pre-Win95 OSR2 GetDiskFreeSpace API call, when the EX version is not available. That's, BTW, the M$ recommended way to do it. So those programs are doing exactly what they ought to, and are not buggy.
II) From Win95 OSR2 up to Win XP (and probably Vista
III) At the .VxD level, all the drive's API are implemented twice: a native FAT (12/16/32) API and an Installable File System API (IFS), for which just two clients are provided: the Network Redirector and the CDFS subsystem. Those two are prsent in windows at least from Win 4 Workgroups 3.11 up to now. The CDFS subsystem is what interests us now, and it consists of an inner layer of stactic VxDs (IFSMGR and VCDFSD) and an outer layer of dynamically loaded VxDs (CDFS, CDVSD and CDTSD). If I'm not mistaken, the inner implementation of GetDiskFreeSpace is in VCDFSD.VxD, which does not provide its sister GetDiskFreeSpaceEX. Why? Because there ate no CD greater than 870 MiB (the very rare 99 min CDs!), the usual, nowadays being 700 MiB maximum capacity, and at the time nobody though that there might be CDFS DVDs.
Hence the CDFS support remained without support for GetDiskFreeSpaceEX, because CDFS DVDs were overlooked at that point, and remained so up to and including Win ME. Thus CDFS DVDs can only be queried through the legacy GetDiskFreeSpace, which, on overflow, returns the infamous 2.147.450.880 bytes size. Now, then, grafting an all-new .VxD to VCDFSD.VxD, just to provide GetDiskFreeSpaceEX for CDFS all the way up to Kernel32.DLL, is possible, but it requires some really serious reverse-engeneering effort that is way more time consuming than devising the usual patch.
Update (Jul 04, 2009): RLoew devised a freeware patch to CDFS.VxD, which resolves this issue.

MDGx forever!