@FILESIZE ... allocated space

#1
DIR /G gets it right (agrees with GetCompressedFileSize()).
@FILESIZE[file,b,a] gets it wrong.

Code:
v:\> d 0.btm
2018-03-26  21:45          11,591  0.btm

v:\> d /g 0.btm
2018-03-26  21:45           4,096  0.btm

v:\> echo %@filesize[0.btm,b]
11591

v:\> echo %@filesize[0.btm,b,a]
12288
 
#5
When does it work correctly? I use NTFS. Is that a bad one? @FILESIZE[,,a] seems to always give the (uncompressed) file size rounded up to the size of an allocation unit.

It seems @FILESIZE[,,a] would benefit from using GetCompressedFileSize (as DIR /G does). In fact, in just a few tests, GetCompressedFileSize acutally returns a multiple of the allocation unit. Below (last command) @IPOW gives the result of GetCompressedFileSize (with no tinkering); I don't think it's a coincidence that the three compressed sizes are multiples of 4096! And GetCompressedFileSize gives the normal size if the file is not compressed.

Code:
v:\> d /s v:\0.btm;cksum.exe
2018-03-26  21:45          11,591  0.btm
2017-01-15  14:30          47,104  cksum.exe
2017-01-15  14:30          53,760  cksum.exe

v:\> d /s /g v:\0.btm;cksum.exe
2018-03-26  21:45           4,096  0.btm
2017-01-15  14:30          32,768  cksum.exe
2017-01-15  14:30          36,864  cksum.exe

v:\> do f in /l v:\0.btm v:\cksum\32\cksum.exe v:\cksum\64\cksum.exe ( echo %@IPOW[%f] )
4096
32768
36864