Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Finder unresponsive on APFS with 3rd Party SSD
- Thread starter haralds
- Start date
-
- Tags
- apfs finder
- Sort by reaction score
Finder is unfortunately the worst. I would personally back up everything and do a nuke and pave if that is at all possible.
You are not alone, there are several threads at discussions.apple.com regarding slow/unresponsive finder, finder not populating directories and other strange behaviour when using apfs, sometimes even forced finder restarts are needed.
I've seen myself directories on apfs enabled drives on different machines where files did not show up in finder or with a significant delay only. (Files that have definitely been touched and are available.)
Directories with large number of files seem to worsen the situation.
Also having open/running applications with a large number of possible open file handles (e.g. huge number of tabs open in browser with large picture galleries like flickr/tumblr, complex source code compilation builds or similar) seem to slow down finder and overall performance of the file system a lot on apfs drives.
There are also a bunch of open source projects with open tickets/issues where builds fail reproducible <only> on apfs enabled machines. I, e.g. had lots of trouble to compile glibc and gcc from source as the build failed on different afps high sierra machines with various file not found errors, where, when checked in the directory itself, the files the build process complained about (generated at runtime) were existing. High Sierra systems with HFS+ drives compiling without any complaints.
Symbolic links seem especially a cause of failure where the symlinks can not be referenced to their origin files (which were available when checked manually).
Current workarounds there are e.g. running tasks single threaded on affected systems (which indicate race conditions) or not using ln -s but to do a dedicated cp, which at least seems to remedy the issue with symlinks at least.
In some conditions MacOS seems to report successful file system operations to applications on apfs systems, which actually may be still in progress.
It seems like APFS probably has somewhere a bug where files or file handlers are not flushed to disk in a timely manner or face some race conditions and synchronisation issues on MacOS layer itself, leading to beachballing the finder or delaying displaying of files in directories and overall performance of the file system.
All in all, I have a bad feeling sth. may be terribly wrong with apfs file handling on operating systems layer, me having filed a couple of bugs regarding this complex.
I've seen myself directories on apfs enabled drives on different machines where files did not show up in finder or with a significant delay only. (Files that have definitely been touched and are available.)
Directories with large number of files seem to worsen the situation.
Also having open/running applications with a large number of possible open file handles (e.g. huge number of tabs open in browser with large picture galleries like flickr/tumblr, complex source code compilation builds or similar) seem to slow down finder and overall performance of the file system a lot on apfs drives.
There are also a bunch of open source projects with open tickets/issues where builds fail reproducible <only> on apfs enabled machines. I, e.g. had lots of trouble to compile glibc and gcc from source as the build failed on different afps high sierra machines with various file not found errors, where, when checked in the directory itself, the files the build process complained about (generated at runtime) were existing. High Sierra systems with HFS+ drives compiling without any complaints.
Symbolic links seem especially a cause of failure where the symlinks can not be referenced to their origin files (which were available when checked manually).
Current workarounds there are e.g. running tasks single threaded on affected systems (which indicate race conditions) or not using ln -s but to do a dedicated cp, which at least seems to remedy the issue with symlinks at least.
In some conditions MacOS seems to report successful file system operations to applications on apfs systems, which actually may be still in progress.
It seems like APFS probably has somewhere a bug where files or file handlers are not flushed to disk in a timely manner or face some race conditions and synchronisation issues on MacOS layer itself, leading to beachballing the finder or delaying displaying of files in directories and overall performance of the file system.
All in all, I have a bad feeling sth. may be terribly wrong with apfs file handling on operating systems layer, me having filed a couple of bugs regarding this complex.