Apple Core Rot extends to all areas of macOS. See Apple Core Rot: There are great things and hundreds of little ones, which together add up to chaos and also Apple Quality Control: Enough is enough.
MacOS Finder should be solid, but it is good with errors, some very serious. See also A file for Finder file copying: Is it even safe to count on MacOS Finder to copy files?
Folder bugs "Zero bytes"
Update: This error also applies to files, and I saw this bug back in 2016 and 2017:
This error occurs on macOS 10.13.6 High Sierra and macOS 10.14.3 Mojave.
This error does not involve using the Finder to copy files; It only exists on its own.
I had about a heart attack when it turned out that 7TB or so of my data was gone. Follow the folders "Zero change" below. OMG. See the following screenshots for more. This was not a temporary thing for a few seconds ̵
Usually if I see a byte folder, I just delete it from the habit. It's a habit I have to unlearn: what if there was only one folder among many andalso shows zero byte … hard to not just destroy the case.
This error is especially serious on hard drives (because they are slow) and when there is disk I / O happening. You can wait a good time to see some view of the size. Why can't it just say "calculation …"? Because it eventually seems to get it right (though I'm not sure).
But it gets worse continues below.
macOS Finder shows "zero byte" for folders containing data
How about making a Get Info on a folder-surely it will be done right, right? Error.
See and see: Finder displays "" for the folder selected above. But it actually has about 58 GB in it.
MacOS Finder displays the "Zero bytes" folder with about 58 GB of data
The folder actually has 58 GB in what can be seen when the folder is opened. So the Finder has all the subfolders together, and many minutes later (or never), the parental applet may show nothing but zero byte. Gorgeous.
MacOS Finder displays folders
But wait, it gets stupid and stupid: here we have a 11.91GB parent folder containing subfolders totaling 509GB or so .
MacOS Finder displays folders
Engineers deserve some guilt
I know that Apple engineers are currently under pressure by calendar-driven deadlines, but tedious work is tricky work. In this case, there is just no extinction for something so bad.
Glenn K writes:
Are your problems all on volumes using SoftRaid? If so, how do you know it's not the problem?
I haven't seen any "zero byte" folders on any of my SSD's, internally or otherwise. Are your problems all on volumes using SoftRaid? If so, how do you know that is not the problem? I have not seen any "zero byte" folders on any of my SSDs, internally or otherwise.
DIGLLOYD: Let me clarify:
- Firstly, Finder does some kind of caching, so when it has the right shape, it seems to "stick" – I actually confirmed this a moment ago – it showed a size (correct) for a parent folder even while the subfolders were listed as zero byte (and on a non-SoftRAID volume too!). So if you open a folder and it gets it right (fast SSD), then no problem. Secondly, if you restart, it seems to remove the problem, even though I have not confirmed what is always true.
- If a driver caused behavioral changes of any kind in any application using file system APIs, that would be a serious problem. I don't know of any technical way that can happen.
- To speak directly to "SoftRAID" non-problem: This error also occurs on a camera card or any station; see the path in the screen of Apple's love for examining data loss risks Continues, informally: Finder displays wrong files as zero byte.
- SSD is much faster than hard drives, especially for directory scans (maybe 100X faster). In this case with half a million files, it takes a loooooong time to scan the HDD. But the point is that if subfolders total up to more than one parent, parents should always have one of two things: "waiting" or the actual size. A parent folder should NEVER display zero byte unless it is completely empty .
- The problem is provoked by I / O activity since I / O activity slows down all other I / O versions, and MacOS is absolutely terrible under heavy I / O load. However, I have seen it under other circumstances where the load is low as well.
- I consider twenty (20) minutes longer after it has the wrong figure. It never got the right shape (before I restarted), so I consider it a mistake.