Friday, February 22, 2019

Finder Shows Incorrect Folder Sizes

Lloyd Chambers:

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 and Get Info also 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).

I haven’t seen zero-byte folders, but I have seen lots of incorrect folder sizes since updating to macOS 10.14. For example, a folder of photos was showing as about 10 GB instead of 100 GB. All of its child folders had underestimated sizes, too. Yet they added up to more than the size shown for the parent folder. This persisted for days. It happens on my iMac’s built-in Apple SSD, so there shouldn’t be any third-party software or hardware to blame.

20 Comments RSS · Twitter

I’ve come across this is 10.14 as well. Last week I updated my iPhone through iTunes, then deleted the ~6GB .ipsw file in the Library/iTunes folder. Before deleting, the folder showed a size of 10GB. After deleting it remained like that for an indeterminate period of time. Eventually it showed 0b. Not sure what triggered it to finally update w the correct size calc.

I also have this issue almost all the time when copying or deleting files. It's super annoying and just another example of how Apple's software quality has been in the toilet lately.

What happened with folder size updates being instantaneous? Showing a folder as containing zero kb when it's not empty is unforgivable.

I see the same problem with "X GB Available" in the Finder status bar often being wrong. I can have "40 GB Available" and then delete 10 GB worth of files and it will still say "40 GB Available" instead of 50 GB for some undetermined amount of time before it shows the correct value.

This is a side effect of the new way APFS calculate folder sizes. This definitively must be improved though.

@Ben G - did you also delete any snapshots containing that directory? The space is used until the last snapshot ages out or is deleted - so that 40GB is probably quite correct.

Wasn't this something that APFS promised to make better?

As usual, something that is basically macOS-only (Finder, filesystem access) is buggy.

"Snapshot" ? WTF is that?

@Bob Yes, but APFS fast folder sizing isn’t actually used.

@Ben APFS snapshot.

APFS has snapshots as one of its features. Here's CarbonCopyCloner explaining them: https://bombich.com/kb/ccc5/leveraging-snapshots-on-apfs-volumes
Here's a pointer to where Apple is using them as part of updates: https://bombich.com/kb/ccc5/leveraging-snapshots-on-apfs-volumes

Cheers, Liam

Fast folder sizing isn’t used!?!. What the heck!?

I get the wrong folder sizes all the time. Finder has really taken a dive in usability.

Interesting. So I guess if I connect my external Time Machine drive more often and do a backup, it will free up "Snapshot" space on my MBP's internal disk?

Any clue about what the cause might be?

If this was a traditional UNIX/Linux system, I would look to see if there are hard-links in there. Many UNIX utilities (like "du") have enough intelligent to not double-count files when the directory being inspected has multiple links to the same files.

If the Finder is doing that, and there are hard-links in the directory tree, that that would explain why the child folders add up to more than the parent.

I know that Apple uses hard-links when migrating a photo library from iPhoto to Photos (throwing off all kinds of usage estimates). I also know that Time Machine uses them extensively. It might be worth looking to see if they are used in the folders where you are observing this problem.

Of course, it could also just be a bug.

Ben G,

Yes, it will. Why don’t you just use an Apple Time Machine and let it handle this for you wirelessly. It just works!

Oh, Apple quit making Time Machines and Airport routers...oops!

I had my Mac telling me my disk was full for about a month. The popup would sometime appear every 5 mintues even if I had moved 40gb+ to an external drive till someday I left "About this Mac" and CMD+i window open all night where it must have decided to calculate the folder right size and stopped showing the annoying popup.

Yeah I've seen that too... I'll let my disk get low (like around 9 GB free) while moving files around, then I'll immediately free up 50 GB or whatever, and Mac OS will still tell me 30 min later "Your disk space is getting critically low" or whatever it is. I'll go and check, thinking I'm crazy, but yeah there's 64 GB free space (and my Time Machine is connected and fully synced, so there's no way a "Snapshot" is taking up mystery space).

Seems like ever since the switch to APFS, there are many lingering bugs regarding file sizes and free space.

You know what I love most about this? When my work MacBook Pro's disk is full and I try to empty the Trash, I get an error message that the Mac can't empty the trash because the disk is full. The Mac not showing all of the space I cleared up when I actually *can* empty the Trash is just the cherry on top of the cake.

@Lukas
Disk too full to empty trash? Well then, that must leave you in a pickle. How do you fix it?

[…] Previously: Finder Shows Incorrect Folder Sizes. […]

I couldn't find answers to a similar issue I was having anywhere on Google. I was getting incorrect folder sizes on a lot of folders on an APFS drive. I realized that it was likely caused by using GoodSync to copy data from my laptop to a target drive with "Copy System Files/Folders" turned on. Doing that, I believe copied over the .DS_Store files from my source to the target. The fix was to delete ALL .DS_Store files on the target drive. Once I did that, all the Folder size calculations went very fast and all folder sizes are being reported correctly now!

another report: Simply renaming a large directory (in the finder using the normal select->edit text mode then paste the new name UI flow) containing large subdirectories (photos libraries) INSTANTANEUOUSLY causes this problem for me with some or all of the subdirectories (photos app libraries) themselves as well as the enclosing renamed directory reporting 0KB or less than the correct sizes immediately. These never seem to fully correct by just waiting without actively doing something like copying everything to a new location or multiple reboots/days transpire etc. Restarting the finder is definitely not enough, nor is toggling the finders calculate all folder sizes for any of the problem items or containers thereof... Problem occurring on MacOS 10.14.6 HFS+ external hard drive, macOS is on internal APFS SSD of course. The observation that renaming can repeatedly cause this problem (the prior valid (aka apparently correct) sizing info instantly gets mangled) should be of some help in figuring out where exactly the issue is. My problem directory is about 750GB and consists of just 6 or 7 photos libraries ranging from a tiny 2.5GB one to the largest one being ~317GB. renaming the enclosing folder constantly mangled the calculated sizes across multiple drives with identical backups -- the directory contents itself is still intact of course but this is truly an unnacceptable bug or design and implementation problem for a filesystem or its GUI to have, let alone have for years... Tempting to do a RE deep dive on this but that is really Apple's job and surely their own Finder and filesystem engineers are more than well aware of these now longstanding issues. This is essentially a data loss bug in end user form as it is lying to the user and unnecessarily (further) breaking the users model of reality and trust in the platform -- problematic for numerous reasons that I won't bother to further enumerate as everyone here is surely well aware of small multitudes of them. The real question is how this issue (and others like it) was ever allowed to ship like this and remain unaddressed thru time despite all the direct and public public reports. The obvious minimal viable and temporary non-fix patch is simply to not display known wrong or uncertain sizes as if they were actually known in any case where the uncertainty could in fact be significant... (yes that would be anytime ever, so do not display BS at all) while working on a proper engineering solution that does actually solve the problem in the way we all want and need it solved. Using a recent variant (or any variant at any time for that matter) of macOS in 2020 shouldn't require regressing to an f5 to refresh circa 1995? MS Windows approach -- hell we can't even do anything a simple as press F5 to fix the finders display of directory sizes is how bad this ongoing relatively newly minted problem is.

I had the same issue and got here after a search. I used the Terminal and did a `du -h --max-depth 1` which gave me the correct sizes and fixed the size in the Finder as wel.

Leave a Comment