First, to demonstrate the situation, the following commands and their results:
At first, this kind of surprised me, but then I remembered the (probable!) reason:
I'd turned disk compression on on my RAM disk a while back and had entirely forgotten about it (no surprise, there!).
Now I'll note that there are a lot of arguments for/against disk compression, and I don't intend to get into any of them. I'll just note three things:
#1. I do not have compression turned on for any of my physical hard disks, just the RAM disk which isn't all that large (234 Megabytes).
#2. I have been told (although I fully admit that I know of no simple way of verifying this) that for small files (which most of the files on my RAM disk are most of the time), compression has very low, if not essentially zero, cost. This is because files less than one cluster in size are not compressed at all.
#3. I've never noticed anything even close to a performance hit on this RAM disk, virtually all disk operations are effectively instantaneous. That could be because the CPU in this laptop is dual-core with a clock speed greater than 3GHz, but if that's the case it means that compression is probably worthwhile even in (at least some) directories of my physical hard disks.
And to verify just how little performance impact there is, I copied the entire contents of the RAM disk to another RAM disk and timed it. This was 676 files, (only) 6,230,016 bytes so maybe not a real good test, but it is a RAM disk and space is quite limited. It takes only 1.61 seconds to do this copy, which isn't a whole lot of time by any measure. (In fact, this is making me consider compressing some directories on my hard disk(s).)
So the bottom line is that I think that there should be at least one way to get @FileSize to report the true amount of disk space taken up by a file, not just it's "theoretical" size.
Code:
[Z:\Copy]echo %@Comma[%@fileSize[dos\Deleted.btm,b,a]]
36,864
[Z:\]PDir /(zca zc fpn) Z:\DOS\Deleted.btm
12,288 34,422 Z:\DOS\Deleted.btm
Code:
[Z:\]attrib Z:\dos\Deleted.btm
___A______C____ Z:\dos\Deleted.btm
Now I'll note that there are a lot of arguments for/against disk compression, and I don't intend to get into any of them. I'll just note three things:
#1. I do not have compression turned on for any of my physical hard disks, just the RAM disk which isn't all that large (234 Megabytes).
#2. I have been told (although I fully admit that I know of no simple way of verifying this) that for small files (which most of the files on my RAM disk are most of the time), compression has very low, if not essentially zero, cost. This is because files less than one cluster in size are not compressed at all.
#3. I've never noticed anything even close to a performance hit on this RAM disk, virtually all disk operations are effectively instantaneous. That could be because the CPU in this laptop is dual-core with a clock speed greater than 3GHz, but if that's the case it means that compression is probably worthwhile even in (at least some) directories of my physical hard disks.
And to verify just how little performance impact there is, I copied the entire contents of the RAM disk to another RAM disk and timed it. This was 676 files, (only) 6,230,016 bytes so maybe not a real good test, but it is a RAM disk and space is quite limited. It takes only 1.61 seconds to do this copy, which isn't a whole lot of time by any measure. (In fact, this is making me consider compressing some directories on my hard disk(s).)
So the bottom line is that I think that there should be at least one way to get @FileSize to report the true amount of disk space taken up by a file, not just it's "theoretical" size.