@FILESIZE ... allocated space

[vefatica]

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

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

 

[rconn]

See the docs for @FILESIZE - it does say that compressed drives do not report allocated sizes accurately.

 

[vefatica]

See the docs for @FILESIZE - it does say that compressed drives do not report allocated sizes accurately.

The drive is not compressed. The file is compressed.

 

[rconn]

The drive is not compressed. The file is compressed.

There's no difference as far as the APIs are concerned.

 

[vefatica]

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.

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

 

[rconn]

I could do that, but at the cost of vastly slowing down @FILESIZE when you're querying folders or wildcards. (Like, an order of magnitude.)

 

[vefatica]

I could do that, but at the cost of vastly slowing down @FILESIZE when you're querying folders or wildcards. (Like, an order of magnitude.)

That would seem better than it being wrong.

 

[rconn]

That would seem better than it being wrong.

It's not "wrong", it's simply not supported (as documented).