Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

@FILESIZE ... allocated space

May
12,846
164
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
 
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
 
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.
 

Similar threads

Back
Top