I think that is the correct behaviour though. The default is left empty in this case, so it should indeed be zero bytes.
Keep in mind that for each file you can have multiple data-streams. Suppose the system reports the total of al the streams for foo combined... You would be surprised if you would read the reported number of bytes from foo and see it crash because there are in reality no bytes in the default stream.
However, there are other tools to report the presence of alternative streams. This is not a feature intended for casual end-users.
The user should not have to use a third-party tool to interact with a feature which is always present in the core OS.
The principle of least surprise applies here: it’s surprising for a user to find a seemingly-empty file, especially if they expect the file to contain valuable data.
Clearly, Explorer should make the presence of multiple streams obvious to the user.
If I dump a SQL database to a file and see that the file size is 0kb in explorer I will assume there was something wrong during the export. Not that the data is hiding in another place which requires me to use special tools to inspect, how am I supposed to know these tools exist in the first place anyway? Explorer is clearly doing the wrong thing here.
This sounds like a bug in SQL server also, what if you try to transfer the data to another computer using a fat32 USB stick, then none of the actual data will be copied.
Keep in mind that for each file you can have multiple data-streams. Suppose the system reports the total of al the streams for foo combined... You would be surprised if you would read the reported number of bytes from foo and see it crash because there are in reality no bytes in the default stream.
However, there are other tools to report the presence of alternative streams. This is not a feature intended for casual end-users.