I regularly move/copy/remove files from the terminal using mv/cp/rm shell commands. With Catalina (10.15.5), file system updates are not reflected in the Finder windows until several minutes later. That is, I can rm a file and it will still show up in the corresponding Finder window for at least several minutes.

How should I go about diagnosing this behavior? Could any of the following be contributing to it, and if so, how?

  • If the folder is on an SSD formatted with HFS+ rather than AFPS
  • Whether the folder is on a disk image and/or one with encryption
  • Whether there are 1000+ files in the folder
  • File sizes and/or types

One thing that does work is running disk first aid from Disk Utility or diskutil verifyVolume after any of these commands.

  • Are you saying that you are experiencing this behavior on an HFS+-formatted SSD with 1000+ files that is encrypted and mounted from a disk image? Or is it an issue with the Finder with any folder and file on your Mac? (For the record, I'm on Catalina and don't see such a delay.)
    – jaume
    Jul 13 '20 at 9:57
  • @JohnD It would be good if you could offer something more information on the situation where you have actually observed this problem. I.e. is it on an APFS disk? - Was it a disk image? Was it encrypted? Were there 1000+ files in the folder? Abnormal file sizes? - As I've written a week ago, this is not something that commonly happens - so please describe the environment you have.
    – jksoegaard
    Jul 13 '20 at 13:06
  • I've been testing every variation of files type/sizes and disk formats. The worse of it is on an encrypted partition of an external hard drive (extended, journaled, encrypted) that has many thousands of iPhone-sized photos organized into folders by year, month and date. Some folders have ~100 images and some only 10. The problem is exclusively with the Finder. If I mv files from the terminal they get moved and I can see the changes instantaneously in the affected directories, but the corresponding Finder window does not refresh for several minutes in the worst case.
    – John D.
    Jul 14 '20 at 6:27
  • I think if anything whether the volume has journaling enabled or not, and if it does, where it keeps its fs journal might cause something like this. Also, it just came to mind because you mentioned both disk images and thousands of files, is the disk image actually a sparse bundle? Jul 15 '20 at 4:13

Just to set a base line, I can say that my Catalina installation does not exhibit any such delay for updating Finder windows. Doing mv/copy/remove operations from the Terminal updates the Finder windows immediately.

This is on Catalina 10.15.5 on an encrypted APFS SSD, and works with any file size and file type (as far as I can tell).

  • This is my experience as well - never seen a delay that was long enough to measure with a stopwatch and human eyes...
    – bmike
    Jul 13 '20 at 9:57

What I'd do as a first check would be to run ls -lrt directly after you remove a file and verify that way that the file is indeed gone. Or use this after moving a file and seeing how they do that way. Removing a file with rm should be an immediate action. Checking if it has indeed been removed should show up in the ls -lrt command. or if you do have a lot of files try

ls -lrt | grep filename

and the file should be gone.

This will tell you if the delay is real

  • The delay is not "real" in the sense you describe. There is no delay from the perspective of the command line commands like ls, mv, etc. Obviously a big file still takes time to move but rm and mv take as long as you'd expect for a small number of files. The delay is purely from the Finder. And this is across SSDs (internal and external) and using a MBP with 32 gigs of memory and plenty of free space on every drive in question.
    – John D.
    Jul 13 '20 at 3:22
  • ok, sorry. i misunderstood your question.
    – Natsfan
    Jul 13 '20 at 14:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .