7 ms·

MacOS Finder Shows Zero-Size Folders

61 points by arm 8y ago

bunnycorn 8y ago
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.
- giancarlostoro 8y ago
  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.
  - Dylan16807 8y ago
    > 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?
    - giancarlostoro 8y ago
      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.
      - Dylan16807 8y ago
        > 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?
        giancarlostoro 8y ago
        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-files/wrong-calculation-of-folder-size-by-windows/2da61a1b-d2fd-472a-ae12-a17a4cc8f7e2 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.
        Dylan16807 8y ago
        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
        zenexer 8y ago
        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.
  - bunnycorn 8y ago
    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-48.png 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-00.png https://i.postimg.cc/66n09YfC/Screenshot-2019-02-25-at-08-05...
- arghwhat 8y ago
  > ... 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? :)
  - hellofunk 8y ago
    It’s an expression that has nothing to do with quantity.
  - culturestate 8y ago
    I'll be the other guy: https://www.merriam-webster.com/dictionary/much%20less https://www.merriam-webster.com/dictionary/much%20less American colloquialisms are fun.
    - arghwhat 8y ago
      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.
      - Dylan16807 8y ago
        "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".
    - Dylan16807 8y ago
      "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.
- mamcx 8y ago
  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!
- apple4ever 8y ago
  I've been a user for years, and until APFS, I've never seen it. I see it all the time now.
threeseed 8y ago
> 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.
- brigade 8y ago
  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.
  - iceninenines 8y ago
    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. :(
  - apple4ever 8y ago
    Except Apple doesn't use fast directory sizing...
- iheartpotatoes 8y ago
  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.
mirimir 8y ago
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.
- arghwhat 8y ago
  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.
  - mirimir 8y ago
    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-addresses-and-usenet-posts.741347/ https://www.velocityreviews.com/threads/tracking-ip-addresse...
PakG1 8y ago
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.
- latchkey 8y ago
  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.
  - PakG1 8y ago
    Yeah, tried that already, no dice. :(
- MilaM 8y ago
  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}
- saagarjha 8y ago
  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.
Aloha 8y ago
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.
- ioulian 8y ago
  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
ksec 8y ago
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.
iceninenines 8y ago
This is a variant of very old behavior. Large folders take a long time to appear because of the need to walk all of the metadata. Heck, 15 years ago, Windows AFS shares on a server would take 90 minutes to become active due to the need to enumerate and update metadata on several million files on a SAN volume that should've been broken up into smaller shares. Folder inodes could cache the size and number of items within them, but this would get very expensive on copies, moves, deletes, renames and resizing files. The best thing would be to efficiently cache metadata in RAM such that apps like Finder can extract metadata more quickly and derive what they need without causing a bunch of random IO going all over the place on spinning rust. Alternatively, buy fast RAM and SSDs with faster read IOPS. There might be some xnu sysctls that would help too. Looking for someone to blame because technology can't defy the laws of physics comes off as behaving like a spoiled, demanding consumer rather than understanding the engineering of why it takes a long time to summarize large folder structures and why there's not a satisfactory way around it without impacting something else. Blame doesn't solve anything, especially if someone doesn't understand what's happening. Let's not do that; it seems infantile.
whiney 8y ago
This guy needs some cheese to go with his whine.
tokyodude 8y ago
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 https://www.youtube.com/watch?v=zdAoe-urFrQ#t=0m30s
the6threplicant 8y ago
I seem to find different coloured folders and inconsistent line spacing when listing folders in column view but not this problem.
ungzd 8y ago
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.
- hollerith 8y ago
  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.
- ungzd 8y ago
  Update: seems that "fast size" feature was cancelled or is not yet ready: https://eclecticlight.co/2019/02/06/how-big-is-that-folder-what-happened-to-apfs-fast-directory-sizing/ https://eclecticlight.co/2019/02/06/how-big-is-that-folder-w..., https://forums.developer.apple.com/thread/79901 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).
Gorbzel 8y ago
File a Radar.
- apple4ever 8y ago
  Which is a black hole where nothing happens
olliej 8y ago
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.
lupinglade 8y ago
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.
hrbf 8y ago
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.

61 points by arm 8y ago

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.

giancarlostoro 8y ago
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.
- Dylan16807 8y ago
  > 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?
  - giancarlostoro 8y ago
    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.
    - Dylan16807 8y ago
      > 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?
      - giancarlostoro 8y ago
        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-files/wrong-calculation-of-folder-size-by-windows/2da61a1b-d2fd-472a-ae12-a17a4cc8f7e2 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.
        Dylan16807 8y ago
        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
        zenexer 8y ago
        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.
- bunnycorn 8y ago
  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-48.png 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-00.png https://i.postimg.cc/66n09YfC/Screenshot-2019-02-25-at-08-05...
arghwhat 8y ago
> ... 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? :)
- hellofunk 8y ago
  It’s an expression that has nothing to do with quantity.
- culturestate 8y ago
  I'll be the other guy: https://www.merriam-webster.com/dictionary/much%20less https://www.merriam-webster.com/dictionary/much%20less American colloquialisms are fun.
  - arghwhat 8y ago
    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.
    - Dylan16807 8y ago
      "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".
  - Dylan16807 8y ago
    "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.
mamcx 8y ago
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!
apple4ever 8y ago
I've been a user for years, and until APFS, I've never seen it. I see it all the time now.

threeseed 8y ago

> 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.

brigade 8y ago
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.
- iceninenines 8y ago
  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. :(
- apple4ever 8y ago
  Except Apple doesn't use fast directory sizing...
iheartpotatoes 8y ago
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.

mirimir 8y ago

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.

arghwhat 8y ago
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.
- mirimir 8y ago
  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-addresses-and-usenet-posts.741347/ https://www.velocityreviews.com/threads/tracking-ip-addresse...

PakG1 8y ago

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.

latchkey 8y ago
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.
- PakG1 8y ago
  Yeah, tried that already, no dice. :(
MilaM 8y ago
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}
saagarjha 8y ago
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.

Aloha 8y ago

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.

ioulian 8y ago
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

ksec 8y ago

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.

iceninenines 8y ago

This is a variant of very old behavior. Large folders take a long time to appear because of the need to walk all of the metadata. Heck, 15 years ago, Windows AFS shares on a server would take 90 minutes to become active due to the need to enumerate and update metadata on several million files on a SAN volume that should've been broken up into smaller shares. Folder inodes could cache the size and number of items within them, but this would get very expensive on copies, moves, deletes, renames and resizing files. The best thing would be to efficiently cache metadata in RAM such that apps like Finder can extract metadata more quickly and derive what they need without causing a bunch of random IO going all over the place on spinning rust. Alternatively, buy fast RAM and SSDs with faster read IOPS. There might be some xnu sysctls that would help too. Looking for someone to blame because technology can't defy the laws of physics comes off as behaving like a spoiled, demanding consumer rather than understanding the engineering of why it takes a long time to summarize large folder structures and why there's not a satisfactory way around it without impacting something else. Blame doesn't solve anything, especially if someone doesn't understand what's happening. Let's not do that; it seems infantile.

whiney 8y ago

This guy needs some cheese to go with his whine.

tokyodude 8y ago

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 https://www.youtube.com/watch?v=zdAoe-urFrQ#t=0m30s

the6threplicant 8y ago

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

ungzd 8y ago

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.

hollerith 8y ago
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.
ungzd 8y ago
Update: seems that "fast size" feature was cancelled or is not yet ready: https://eclecticlight.co/2019/02/06/how-big-is-that-folder-what-happened-to-apfs-fast-directory-sizing/ https://eclecticlight.co/2019/02/06/how-big-is-that-folder-w..., https://forums.developer.apple.com/thread/79901 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).

Gorbzel 8y ago

File a Radar.

apple4ever 8y ago
Which is a black hole where nothing happens

olliej 8y ago

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.

lupinglade 8y ago

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.

hrbf 8y ago

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.