Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

Finder slow to show large folder contents - "loading"

H

HDFan

Contributor
Original poster
Jun 30, 2007
7,472
3,535
After the upgrade to Ventura file operations on large directories (~10000 files) can be very slow. Opening a folder in finder, or in an application which opens a finder window, I get a "loading" message. Have never seen this message before. This can last for a few seconds or several minutes before the files in the directory show up. After the first population it may or may not happen going back into the directory at a later time.

Demonstrated problem on 2 different external thunderbolt RAID devices as well as a thunderbolt NAS. The problem doesn't seem to happen with files on an internal SSD.

Duplicated with Apple support after wiping an external SSD and doing a fresh install of Ventura. They took a screen recording and ran capture data which is being sent to development.

Wondering if anyone else has seen this problem.
 
  • Like
Reactions: BKDad
I have an M.2 SSD in an Orico enclosure. When that is attached, it can occasionally cause slowness when I log in.

Theoretically the disks are mounted by then.. so its not a mount. (In fact I know the disks are mounted because if I leave terminal open and login... I can make unix commands and mount does show the external disk as mounted).


This manifests itself as the desktop taking ages to appear, and seems to have stalled. The disks do NOT appear on the desktop (mostly), and even when they do you cannot double click them (any of them, including the OS internal disk).


Apps open (if previously open), but then they have spinning icons (most of the time)... occasionally they appear functional as long as you don't tdo anything too fruity. Unix Terminal behaves as long as you don't try to navigate to the offending Volume).


The disks appear ok as far as Disk Utility is concerned.


Spotlight appears to be stuck indexing (its not a spotlight problem though.. because even if I disable spotlight this still happens - again intermittently).


BUT - if I just pull out the thunderbolt cable connecting the enclosure... boom the desktop appears and the Mac runs normally. I can then replug in the USB enclosure, and it's all fine (bar the message about not having correctly ejected the disk).



So, it's something to do with access to the disk connected on the thunderbolt port. The disk access light is blinking very rapidly when its doing this.. suggesting access.. but whatever its doing its doing it really slowly and it's blocking everything else.



I am getting another (different company) enclosure today... and I'll be able to narrow it down if this one works.



However if the new one behaves the same, then it suggest the OS is performing some kind of blocking activity that prevents any other IO until that has completed whatever its doing.
 
Anybody discover anything?

I'm using an external Thunderbolt RAID drive with a Studio running Ventura. The drives are all HDD's formatted, per Apple's suggestion, as Mac OS Extended (Journaled). I have a folder in one of the volumes where I collect various articles that I Export as PDF from Safari.

Here's the problem. When I click on Export as PDF, the window pops up and takes about 20 seconds for the directory to populate. It's as if it never was indexed.

This did not happen with the same system previously used with an iMac running Mojave. The directory population was instant.

Ventura "feature"?? Is there a workaround?

The files on the RAID system are all non-working files. By that, I mean that they are saved files that I want to get to easily, but they aren't being edited or worked on. That's where I store podcasts, music, photographs, articles, and so on. Files that actually are being worked with stay on the internal drive until they're done, when they get moved to this external RAID system. So, high speed isn't necessary. But, this directory thing is dopey.
 
BKDad said:
When I click on Export as PDF, the window pops up and takes about 20 seconds for the directory to populate. It's as if it never was indexed.

This did not happen with the same system previously used with an iMac running Mojave. The directory population was instant.

Ventura "feature"?? Is there a workaround?
Click to expand...

Which RAID device do you have?

My Promise RAID can take several minutes to populate large directories (thousands of files) since the Ventura upgrade. No problems with previous OS version. Worked with Apple Support for a while without a resolution, although I didn't keep pushing. Filed a feedback report and it is marked as no other reports of the problem.

If you file a feedback report then that will increase the odds that they might actually look at it.

Waiting for the Sonoma upgrade. If that doesn't fix it then will continue to pursue.
 
I have the same problem. T3 external with 4 HSF+ disks, all 6-8 TB, always worked properly on my old iMac Pro / Monterey. Never any hesitation bringing up everything on a 8 TB disk of RAW image files. Then I got a M2 Studio, Ventura, and the whole thing bogs down. Super annoying.
 
  • Like
Reactions: BKDad
I've always found macOS to be slow when loading large directories. It's one of the reasons I started using ForkLift, along with the MUCH faster connection to external servers over VPN.
 
MacGizmo said:
I've always found macOS to be slow when loading large directories. It's one of the reasons I started using ForkLift, along with the MUCH faster connection to external servers over VPN.
Click to expand...
I don't know whether I'll keep Forklift but I surely am liking it. It displayed the material on the 8 TB disk in, oh, maybe a second. Amazing. At least now I know I don't have a hardware problem -- it's a Finder issue. Thanks for the suggestion -- I appreciate it.
 
  • Like
Reactions: MacGizmo
monokakata said:
I don't know whether I'll keep Forklift but I surely am liking it. It displayed the material on the 8 TB disk in, oh, maybe a second. Amazing. At least now I know I don't have a hardware problem -- it's a Finder issue. Thanks for the suggestion -- I appreciate it.
Click to expand...
No problem. Oddly, I first tried Forklift for the interface replacement for the Finder. But now I don't even care about that, I just like it because it's so much faster than the Finder (particularly for remote access to servers).
 
monokakata said:
It displayed the material on the 8 TB disk in, oh, maybe a second. Amazing.
Click to expand...

Interesting. Same here, Forklift works fine. If it still happens with Sonoma that will be good evidence that it is a Finder problem.
 
HDFan said:
Which RAID device do you have?

My Promise RAID can take several minutes to populate large directories (thousands of files) since the Ventura upgrade. No problems with previous OS version. Worked with Apple Support for a while without a resolution, although I didn't keep pushing. Filed a feedback report and it is marked as no other reports of the problem.

If you file a feedback report then that will increase the odds that they might actually look at it.

Waiting for the Sonoma upgrade. If that doesn't fix it then will continue to pursue.
Click to expand...
Sorry for the late reply.

I am using an OWC Thunderbay 4 with Toshiba spinning drives.

Like you, it worked before I, ahh, upgraded to a faster computer running Ventura.
 
Chiming in here, came from Google. Same problem here, G-Speed Thunderbolt 3 RAID, Mac Studio M2 Ultra, Ventura. This didn't use to be a problem.

My driver is also Promise. Do we need to be talking to Promise about this?

(G-Tech support (now Western Digital) was absolutely useless as always, and asked if my raid was connected directly to wall power.)
 
titaniumdoughnu said:
Do we need to be talking to Promise about this?
Click to expand...

I've talked with them and they indicated they saw no problem. Since this also happens on other external devices, does not happen in Forklift, surely points to a Finder problem.
 
  • Like
Reactions: BKDad
An update to Ventura 13.6 doesn't solve this.

Somehow, this doesn't feel like a bug. It seems like this is the way it's designed to work for some reason. Maybe Apple wants to kill the desire for external drives, except for those in the cloud. Who knows.

I've found that that the report filing and reporting system at Apple isn't great. I had a memory problem with a 2015 iMac. Apple support insisted that nobody had ever reported such a thing. Then I spent some time interacting with Google and found that lots of people - no idea how many - had the exact same issue. An iMac owner from the UK had his computer replaced for free because of the problem and had an Apple representative there explain it all to him, which he then conveyed to the world. I then tried again with Apple support. They'd never heard of such an issue...
 
Last edited:
BKDad said:
this doesn't feel like a bug.
Click to expand...

A negative behavior which suddenly appears in the 13th version of the OS certainly looks like a bug to me.

BKDad said:
I had a memory problem with a 2015 iMac. Apple support insisted that nobody had ever reported such a thing. Then I spent some time interacting with Google and found that lots of people - no idea how many - had the exact same issue.
Click to expand...

Quite possibly true. Lots of people report problems on websites but never bother to file feedback reports to Apple. If a system is replace in the UK due to a problem I very much doubt that it would be of any use given the (hundreds, thousands?) of systems that are replaced every day worldwide. I assume that there is some QC group which is tasked to find common problems so that they can be fixed in production. They aren't going to see the issue until it is reported in X number of failures. No reports, no discovery, no fixes.
 
HDFan said:
A negative behavior which suddenly appears in the 13th version of the OS certainly looks like a bug to me.



Quite possibly true. Lots of people report problems on websites but never bother to file feedback reports to Apple. If a system is replace in the UK due to a problem I very much doubt that it would be of any use given the (hundreds, thousands?) of systems that are replaced every day worldwide. I assume that there is some QC group which is tasked to find common problems so that they can be fixed in production. They aren't going to see the issue until it is reported in X number of failures. No reports, no discovery, no fixes.
Click to expand...

If the slow directory display on large folders had always been the case in earlier versions of macOS, nobody would notice. They'd just figure that this is the way it is and must be. But, that's not the history.

Generally, bugs happen because of some change in the code in the system. It's not as if they spontaneously appear out of the blue. What you reported in your initial post to this thread, and lots of people including me also observed and reported, is pretty blatant. It's not some subtle event that requires a strange combination of hardware and software apps. It happens with stock Apple applications, like the Finder! You might even think that it would be encountered in routine regression testing, especially after well more than a year of alphas, betas, and actual field deployment.

How do we know that Apple considers this negative behavior? They don't say a word about it either way. Sometimes it appears that they half-deprecate a feature or behavior without saying anything. Perhaps they want to, ahh, encourage the use of APFS formatted drives for security reasons. They don't tell us their strategies on things. I'm not saying they should, but often it might be helpful. In this case, a couple sentences somewhere on the Apple website would save people whining about the problem with on websites and through their customer help system. That's if this is really a deliberate design decision and not an actual bug that's being ignored. Apple's consistent silence about pretty much everything not only helps with product surprises but also could be a way to manage things they don't want to deal with.

~~~

Several of the people who reported the iMac problem on various websites, including this one, claimed to have reported the problem to Apple. They all certainly went through the Apple help system - that's how they got the responses they did from the help line people. Obviously, the owner who got his iMac replaced by Apple reported something to somebody. And, the UK Apple people seemed to have known about the problem. Are you saying that Apple engineering doesn't read reports from the people staffing the various means of contacting them?
 
Good news. Got an Apple Support engineer who gave me some insights into how their bug reporting system works. My interpretation of what he said was that there are 3 phases:

1. Ticket or investigation phase. Support sends tickets to development to give them the information they need to reproduce, define and isolate the problem.

2. Feedback or voting phase. Customers "vote" on the fix by submitting feedback. I.E. each feedback submission on the issue is assigned as a vote for that fix

3. Implementation phase - the fix is allocated resources and eventually ends up in released code

Within all categories there is likely prioritization based upon bug severity and # of reported customers affected

Development is no longer accepting tickets for this problem so it is now in the voting phase. Depending upon the number of "votes" for the fix and their opinion of the bugs severity it will go to implementation at some point in the future.
 
  • Like
Reactions: BKDad
HDFan said:
Good news. Got an Apple Support engineer who gave me some insights into how their bug reporting system works. My interpretation of what he said was that there are 3 phases:

1. Ticket or investigation phase. Support sends tickets to development to give them the information they need to reproduce, define and isolate the problem.

2. Feedback or voting phase. Customers "vote" on the fix by submitting feedback. I.E. each feedback submission on the issue is assigned as a vote for that fix

3. Implementation phase - the fix is allocated resources and eventually ends up in released code

Within all categories there is likely prioritization based upon bug severity and # of reported customers affected

Development is no longer accepting tickets for this problem so it is now in the voting phase. Depending upon the number of "votes" for the fix and their opinion of the bugs severity it will go to implementation at some point in the future.
Click to expand...

Thanks for the timely update!

I have to say that the response from Apple isn't very satisfying. They broke something that previously worked well, and now they maybe, perhaps, might think about looking into fixing it someday? Imagine if your local hospital broke some internal system used to keep infections to a minimum. Then when somebody complained because they got an infection, the hospital said in response, "Well, we'll think about fixing it if we have enough people die."

For file transfers users can purchase Forklift to get around some of the other Finder limitations. Not so sure what can be done with this one, other than to make sure that all your folders have only a few files in each. That kinda defeats some of the benefits of letting the computer do the searching and organizing, but I guess it's better than using floppy disks.
 
I have a weird theory I'm testing and want to clue others in just in case.

I forgot all about this problem with Dropbox and Quicklook from a few years ago, and figured it might still be there mucking things up. I just ran these commands to get rid of the Dropbox Quicklook plugin, and it *might* have fixed the issue for me.

(For context, Dropbox overwrites the native Quicklook tool with its own, and it caused all manner of problems, from slow Quicklook previews, to no previews at all, system wide, not just in the Dropbox folder. I figured maybe it messes with directory loading, perhaps by running on every icon load to see if they need a Dropbox badge)

 
titaniumdoughnu said:
I have a weird theory I'm testing and want to clue others in just in case.

I forgot all about this problem with Dropbox and Quicklook from a few years ago, and figured it might still be there mucking things up. I just ran these commands to get rid of the Dropbox Quicklook plugin, and it *might* have fixed the issue for me.

(For context, Dropbox overwrites the native Quicklook tool with its own, and it caused all manner of problems, from slow Quicklook previews, to no previews at all, system wide, not just in the Dropbox folder. I figured maybe it messes with directory loading, perhaps by running on every icon load to see if they need a Dropbox badge)

Click to expand...
I think you're on to something. The Dropbox shell extension also puts icons on files in Finder. I notice that Forklift does not do that. It could be that interaction with some third-party application, that might only happen with Finder, could be part of the problem.
 
  • Like
Reactions: titaniumdoughnu
titaniumdoughnu said:
I have a weird theory I'm testing and want to clue others in just in case.

I forgot all about this problem with Dropbox and Quicklook from a few years ago, and figured it might still be there mucking things up. I just ran these commands to get rid of the Dropbox Quicklook plugin, and it *might* have fixed the issue for me.

(For context, Dropbox overwrites the native Quicklook tool with its own, and it caused all manner of problems, from slow Quicklook previews, to no previews at all, system wide, not just in the Dropbox folder. I figured maybe it messes with directory loading, perhaps by running on every icon load to see if they need a Dropbox badge)

Click to expand...

Thanks for the suggestion! I just tried this.

The terminal shell tells me that there is no such directory.
 
BKDad said:
Thanks for the suggestion! I just tried this.

The terminal shell tells me that there is no such directory.
Click to expand...
Yeah, this hasn't worked since Monterey, or maybe even Big Sur. It was whenever Dropbox completely re-wrote the app to Apple's new OS specifications and was really late delivering it. I honestly can't remember the timeline, but it has been a while.

I can't actually find any QuickLook generator files, and I know I have at least two 3rd party apps that install them... I just can't find them.
 
The QuickLook folder in my main Library folder is empty, too.

I wonder if there's a way to flood the Apple "voting" system to give this priority. ;)
 
I see quicklook generators within the application bundles of some applications in the /Applications folder. For example

/Applications/OmniOutliner.app/Contents/Library/QuickLook/OmniOutliner.qlgenerator

If I take the application out of /Applications, the plugin stops working. If I use Finder to put it back into /Applications it starts working again. So /Applications is a special location this regard.
 
So apparently Quick Look extensions are supposed to live inside Apps and not as separate "files" that a user would manually install. The apps that have QL extensions can be found in the Privacy System Settings and can be turned on/off.

System Settings>Privacy & Security>Extensions>Quick Look

quicklook-list.png
 
  • Like
Reactions: BKDad
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back