I've been a user of macOS for years and never seen this in HFS, much less in APFS.

Someone that needs to write anything to fill his blog of a narrative of "Apple is dying".

Also, I'm 100% sure in the old days, it had an indication it was calculating the size when the number wasn't final.

Heck I see this bug on Windows and Linux too. It's just how File Managers work in other OS' they're not perfect. If I know a directory is massive, I don't go by what the OS immediately tells me. A few TB sounds like it would take a long while to fully update, but I bet there's a time out limit.

Currently running macOS Mojave.

I've tested with a SMB share, it says "calculating" when it doesn't know the size of a directory:

https://i.postimg.cc/3xn1sNC6/Screenshot-2019-02-25-at-08-03...

It also shows "--" when in list view:

https://i.postimg.cc/66n09YfC/Screenshot-2019-02-25-at-08-05...

> I see this bug on Windows

What do you mean? The "Size" column is completely empty for directories.

If you right click and open properties on a directory, it will show a size that grows four times per second, very blatantly a calculation in progress.

How do you get this bug on Windows?

I mean the size column can be misleading sometimes while the File Manager figures itself out. Yeah Properties seems to work a little better. It's usually due to larger file sizes. Unlike the OP of the article it doesn't bother me enough, I've just seen it happen across OS' and have not had issues with it, if I need to know a file size, I have other means like the command line, of course sometimes the command line is another culprit of not showing a directory size as well. Like only showing 4 KiB for every directory at least on Ubuntu.

> I mean the size column can be misleading sometimes while the File Manager figures itself out.

On windows? How are you getting that column to not be permanently blank on directories?

I'm on Ubuntu at work and my Windows laptop's at home but there's others who've ran into what I'm talking about:

https://answers.microsoft.com/en-us/windows/forum/windows_10...

Basically: You see one file size on a parent folder, and when you drill in further it changes. I'm surprised these explorers don't try to cache some of the info somehow.

This sounds like someone doesn't understand how Windows calculates folder sizes. It will never show the size unless you look at the folder properties; and even then, there's no indication when it's done calculating. It might be obvious sometimes because the number is continuously changing, but if it hits a lot of very small files, it won't visibly change for a while.

Edit: Actually, apparently there is a bug related to this in recent versions of Windows, but it's still a behavior that can happen even without a bug.

Ah. Though that's still opening the properties dialog, which is much rarer than browsing.

Also they're reporting that it only happens with full filenames over MAX_PATH, so it's a very different bug. The base idea of "show a continuously-increasing size until don't calculating" works fine

> ... never seen this in HFS, much less in APFS.

I can't help myself: If you never see it on HFS, how can you see it less on APFS? :)

I'll be the other guy: https://www.merriam-webster.com/dictionary/much%20less

American colloquialisms are fun.

"He had trouble paying for a car, much less a high-definition TV."

Ha, someone needs to update their examples now that a "high-definition TV" is every TV and $100 gets you a brand new one.

I'll be the first guy again, quoting your link: "used especially in negative contexts to add to one item another denoting something less likely"

American colloquialisms are awkward, but if you dig deep enough, you will find traces of their original meaning shining through, despite the best efforts of the people to eliminate it.

"I've never seen it" is a low likelihood, but it's easy to go lower. Applying "less" to the likelihood of the error is perfectly reasonable. The word "less" is not being compared to "never".

It’s an expression that has nothing to do with quantity.

I read that blog some times (checking for deals, mostly, and reviews) and it look like it.

Until it start happening to me. I get the "this file is 0 bytes" bug for some time.

Is fixed?

I don't know! Is just that the "0 bytes" files was part of my project and the bug manifest other nasty effect... But I can't claim, right now, the bug is not here!

I've been a user for years, and until APFS, I've never seen it.

I see it all the time now.

> I know Apple engineers are pressed for time by calendar-driven deadlines, but sloppy work is sloppy work.

This seems to occur only on Softraid (and maybe SD card) filesystems.

So it's just an edge case that probably never was considered or only manifests until certain circumstances.

Hardly a guaranteed symptom of sloppy work.

Especially with APFS adding fast directory sizing, it's ultimately the responsibility of each individual filesystem driver to calculate directory size. And the driver is also the only code that can tell whether the last returned size is still correct. Which for some filesystems (SMB) it should be impossible to know without traversing the entire subdirectory tree again.

Except Apple doesn't use fast directory sizing...

This is where fast and reliable caching strategies, and lazy, parallel enumeration come in. I would almost want the .DS_Store to include a summary of a tree's metadata and update what's in view by watching watchable filesystems in order to avoid as much full remote tree walking as possible. Shared remote filesystems without a differential/OT push metadata notification API reduce clients to glorified polling. :(

How can you make that claim with a straight face? If you don't know the size of the node/folder/dir and need to compute it, never ever ever ever give a definitive answer that is wrong, give an in progress answer. There should be no "edge" case. We've been writing file managers for 40 fucking years. Sorry, this is just nonsense and pisses me off. There is such a thing as defensive coding.

My wife suddenly lost a ton of photos in her Photos app. I tried finding them, and eventually saw they still existed in the file system, but not in the app. No idea why. Continued researching this. After a few days, they disappeared from the file system too. Makes no sense. Running Sierra. So confused.

This happened to me too, independently on two Macs with different Photos libraries. It's a very strange bug where after a library migration Photos.app will delete some pictures and videos from the Masters folder inside the library. The deleted files still show in the UI because the app uses seperate thumbnails for that. But the original files are gone. I only noticed it because some videos where not playing anymore and also exports of the files did not work.

I tried to narrow down what went wrong. Launching a previous state of the library on Mojave from a backup deleted the same files with the following output in Console:

Photos Import failed during master recovery for path: 2018/10/08/20181008-093231/28f7a73f-1737-4pb6-9275-1c35dwb8a30a.JPG, Error Domain=com.apple.photos.reddwarf.ingest Code=1 "Removed version uuid: Gvj78Pses+eRzULLoWJ83g because imported master was either removed, or chosen as the candidate master during de-dup" UserInfo={NSLocalizedDescription=Removed version uuid: Gvj78Pses+eRzULLoWJ83g because imported master was either removed, or chosen as the candidate master during de-dup}

Try this (after doing a full backup of your wife's ~/Library folder):

Option-Command-O on the /Applications/Photos.app. It'll go into repair library mode and might fix things.

Yeah, tried that already, no dice. :(

I saw this happen with me as well. For some reason Photos somehow completely lost track a couple years of recent pictures. No idea what happened here.

Something like this happens in Linux. With most graphical file managers, folders containing maybe 10^4 files will take a long time to open. At least it doesn't report zero. But you may end up killing the file manager, and working in a terminal.

Not to make application bugs sound acceptable, but if you're dealing with that many files, you should probably have started in the terminal anyway, whether it be Linux or macOS.

It is also a good idea to try to organize your way out of large directories (that is, directories with many immediate children). Some filesystems dislike large directories performance-wise, and manual workflows rarely deal well with very long file sequences.

I've since learned that :) What can I say. I was a n00be, from Windows. And I should add that Debian terminal had no problem with 10^4 or even 10^5 files per directory.

For what it's worth, I was massaging several GB of Newsgroup data into SQL. As I recall, I used grep to decompose the data into components. I crunched one year segments. For each year, each type of header, and message bodies, went into a subdirectory, tagged with the message ID. So in each of those subdirectories, there was one file for each message in the data segment. I did it that way, because each type of component needed custom regex to become SQL fields. In the end, the header types and message bodies became tables, indexed and linked by message IDs.

So anyway, there were lots of temp files.

Why did I do that? You might ask. Well, there was this notorious troll, who was on a vendetta against friends and I. He didn't just post trash. He spoofed our messages, making fun of us, and trying to sow discord. So it was virtually impossible to filter out his shit.

So basically I identified many of his personas, going back a decade or two. And eventually I found posts that included unobscured IP addresses and meatspace email addresses. So I emailed him, and threatened to dox him, if he didn't stop trolling us. So he did. And I never actually doxxed him, because that would have violated his privacy.

It was Ari Silverstein, by the way.[0] None of my personas posted there, but people were aware of my work.

0) https://www.velocityreviews.com/threads/tracking-ip-addresse...

Edit: And in case you search about this, just about everything you find will be Ari Silverstein's word salad.

Well if we're complaining about the finder ... I was recently searching for photos on a network share. Had Finder in "Show as Icons" mode.

I don't know what the actual bug is. Either Finder doesn't show files for which it has not generated an icon yet (ie, it doesn't show a placeholder) or it just for some reason takes forever for the finder to get a list of files. I know getting the the actual list for files for any one folder should not take more than a moment (can do so from terminal to test)

The result is it was basically unusable. I'd scroll down and the finder would be adding and reshuffling the layout of images for 1 to 2 minutes making it impossible to actually use to find things. There's no way to know when it's finished. I'd start to select stuff thinking it had settled down and stuff would shift under my mouse still.

If you look closely here you'll see as I'm scrolling down the files keep shuffling around https://www.youtube.com/watch?v=zdAoe-urFrQ#t=0m30s

This doesn't seem like a huge deal, it happens on Windows and Linux too, if the underlying filesystem is slow, and the data hasn't been cached, which is the best behavior - considering the alternative is to display nothing till all the data arrives.

Previous versions (maybe the new ones too, I haven't seen it yet) of Windows was updating the size realtime when it was still calculating. You could still see the approx size and know it's not the real size.

EDIT: only when opening "properties" dialog

While there certainly are long-standing issues with Finder, this rant is just lazy and sensationalist. No wonder why, looking at the metric ton of ads on the page. This is basically clickbait. The other articles are in a similar tone and spirit. If macOS is really that bad, why use it for servers and do so much with it? Apple has no true enterprise strategy and never had. Whining about something one feels one somehow deserves does not make it so. The other comments are correct: the shown behavior is just how file managers work – especially when dealing with spinning disks over a network share and 7 TB worth of small files.

I seem to find different coloured folders and inconsistent line spacing when listing folders in column view but not this problem.

Was just able to reproduce it on a stock MacBook Pro 2018 SSD, system volume, Mojave. Showed zero bytes until it calculated the size. I think this is a newer bug, it used to say “Calculating…” IIRC.

Update: for other folders, its showing “Calculating size” as it should, so its either an intermittent bug or has some sort of specific trigger.

Few days ago encountered similar bug: Finder reported size of direcrory as about 300 Mb, but actual size was 9 Gb. There were no hardlinks or something like that, content inside was generated by script. This was on apfs, and size was reported instantly, so it might be bug in filesystem, not Finder.

Update: seems that "fast size" feature was cancelled or is not yet ready: https://eclecticlight.co/2019/02/06/how-big-is-that-folder-w..., https://forums.developer.apple.com/thread/79901

So the problem is likely with size caching in Finder.

I tried getattrlist on my system, and ATTR_DIR_ALLOCSIZE is always 0 and ATTR_DIR_DATALENGTH is some unrelated small number (probably size of directory entry in FS, not size of its files).

When Apple converted my root filesystem to apfs, some code I wrote stopped working because on occasion (e.g., right after powering up) my code's attempt to execute a file (namely, /System/Library/ PrivateFrameworks/Apple80211.framework /Versions/Current/ Resources/airport, an ordinary executable file that certainly does exist) would fail with a "file not found" error.

I've seen this fairly regularly for years across hfs and apfs on spinning disks and ssds. I've always /assumed/ it must be some caching bug or what not, though I thought APFS was meant to provide O(1) folder and file size values so wouldn't be necessary.

Finder sometimes has Disappeared Files when browsing NAS drives, whether it is using SMB or AFP. But reconnection will make those files reappear again, and it has been going on for years I sort of gave up reporting. Luckily no data is loss.

File a Radar.

Which is a black hole where nothing happens