alternate streams size not counted

[libit]

DIR /:
shows all file streams however in the final total bytes shown for a directory, the size of alternate streams are not counted (TCC LE 13.06.77 x64)
Same with TREE.

e.g
[C:\Workspace]>dir a.a /:

Volume in drive C is Windows8_OS Serial number is f"£$%&/()
Directory of C:\Workspace\a.a

05/06/2015 14.05 41 a.a
429.455.360 bump:$DATA
429.455.360 largestream:$DATA
899 bytes in 1 file and 0 dirs 4.096 bytes allocated

I wonder where those 899 bytes comes from.

 

[rconn]

Not reproducible here:

[D:\TakeCommand18\tcc]dir wsh.rexh /:

 Volume in drive D is Development  Serial number is 581d:31ad
 Directory of  D:\TakeCommand18\tcc\wsh.rexh

 9/23/2014  23:32  454  Wsh.rexh
      88  ♣SummaryInformation:$DATA
        0  {4c8cc155-6c1e-11d1-8e41-00c04fb9386d}:$DATA 
    542 bytes in 1 file and 0 dirs  4,096 bytes allocated
  343,563,309,056 bytes free

Are you seeing this on all files with streams or only one?

 

[libit]

All files but as you can see I'm using TCC LE v13. Maybe it has been fixed in newer (but non free) versions....

 

[rconn]

My test *was* in TCC/LE v13.

 

[libit]

Ok, I thought that maybe you were using TakeCommand18 (your working dir)
Anyway I tried with small streams as in your case and it worked correctly for me too. Then Tried again with a large alternate stream and failed again.
Try e.g. this:

echo Hi > testas.txt
type \windows\explorer.exe > testas.txt:explorer
dir /: testas.txt

I get:
[C:\...\x]>echo Hi > testas.txt

[C:\...\x]>type \Windows\explorer.exe > testas.txt:explorer

[C:\...\x]>dir /: testas.txt

Volume in drive C is Windows8_OS Serial number is xxasdasd
Directory of C:\Users\x\testas.txt

05/06/2015 17.06 4 testas.txt
2.501.368 explorer:$DATA
6 bytes in 1 file and 0 dirs 4.096 bytes allocated

 

[rconn]

The '.' characters in your file size is confusing the Microsoft RTL function that is determining the stream size. I've fixed it for the next TCMD / TCC version; I may do a TCC/LE update when Windows 10 is released.

 

[vefatica]

I see the same thing here with v17. It looks like it counted 2 bytes instead of 2,616,320.

v:\> dir /k /: str*
2015-06-05  12:19  5  stream.txt
  2,616,320  explorer:$DATA
  7 bytes in 1 file and 0 dirs  4,096 bytes allocated
  6,601,097,216 bytes free

 

[libit]

Weird, why would you read the size from its string representation instead of using the binary value returned by NT APIs?