Apple Core Rot extends to all areas of macOS. See Apple Core Rot: It’s Big Things, and Hundreds of Little Ones, that Together Add up to Chaos and also Apple Quality Control: Enough is Enough.
The macOS Finder ought to be rock solid, but it is rife with bugs, some very serious. See also One more Finder File Copy Bug: Is it Even Safe to Count on the macOS Finder to Copy Files?.
The “Zero bytes” folder bug
Update: this bug also applies to files, and I saw this bug back in 2016 and 2017:
This bug does not involve using the Finder to copy files; it just exists on its own.
I just about had a heart attack when it appeared that 7TB or so of my data was gone. Observe the “Zero bytes” folders below. OMG. See the following screen shots for more. This was NOT a transient thing for a few seconds—after 10 minutes it was still wrong.
Generally if I see a zero byte folder, I just delete it out of habit. That’s a habit I have to unlearn: what if it was just one folder among many andalso shows zero bytes... hard to not want to just trash the thing.
This bug is particularly severe on hard drives (because they are slow) and when there is disk I/O going on. You might wait a looooooooooong time to see any display of the size. Why can’t it just say “calculating...”? Because it eventually seems to get it right (though I”m not sure of that).
But it gets worse, continued below.
How about doing a Get Info on a folder—surely that will be done correctly, right? Wrong.
Lo and behold: the Finder shows “” for the folder selected above. But it actually has about 58GB in it.
The folder actually has about 58GB in it as can be seen when the folder is opened. So the Finder has all the subfolders totalled and many minutes later (or never) the parent folder might show something other than Zero bytes. Lovely.
But wait, it gets stupider and stupider: here we have an 11.91GB parent folder that contains subfolders that total 509GB or so. What a joyous set of clusterbugs.
Engineers deserve some blame
I know Apple engineers are pressed for time by calendar-driven deadlines, but sloppy work is sloppy work. In this case there is just NO EXCUSE for something this bad.
Glenn K writes:
Are your issues all on volumes using SoftRaid? If so, how do you know it isn't the issue?
I have not seen any "zero byte" folders on any of my SSDs, internal or otherwise.Are your issues all on volumes using SoftRaid? If so, how do you know it isn't the issue? I have not seen any "zero byte" folders on any of my SSDs, internal or otherwise.
DIGLLOYD: let me clarify:
- First, the Finder does some kind of caching, so once it has the right figure, it seems to “stick”—I actually verified this just a minute ago—it showed a size (correctly) for a parent folder even while the sub-folders were listed as zero bytes (and on a non-SoftRAID volume too!). So if you open a folder and it gets it right (fast SSD), then no issue. Second, if you reboot, it seems to clear out the problem, though I have not verified that 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 could happen.
- To speak directly to the “SoftRAID” non-issue: this bug also happens on a camera card or any drive; see the path in the screenshot in Apple’s Penchant for IGNORING Data Loss Risks Continues, Unabated: Finder Erroneously Shows Files as Zero Bytes.
- SSDs are far faster than hard drives, particularly 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, if subfolders total up to more than a parent, the parent should always have one of two things: "pending" or the actual size. A parent folder should NEVER show zero bytes unless it is truly empty.
- The issue is provoked by I/O activity since I/O activity slows down all other I/O and macOS is absolutely terrible under heavy I/O load. However, I have seen it under other circumstances where load is low as well.
- I deem twenty (20) minutes rather long for it to have the wrong figure. It never did get the right figure (until I rebooted), hence I deem it a bug.