Finder stalls Could it be ASObjC or FileManagerLib?

AppleScript
#1

I have migrated all of my old scripts that used Finder or System Events for file manipulation to start using FileManagerLib. But I’ve noticed an issue that I think has come up since I started doing that.

If I open a folder that was created or changed by file managerlib, it seems empty, while the finder updates the folder. There is a spinning wheel in the bottom right of the folder’s window, and it can take up to a minute or two for the window to display the contents.

Has anyone experienced this?

Would the Finder’s “update” command help?

Any suggestions?

Slow Finder update of text files
#2

Last I looked, the update command also stripped custom icons.

Are these local directories?

#3

Mostly local. 9 out of 10.

#4

I’m not sure I can offer any advice. There is a Cocoa command called noteFileSystemChanged:, of which the docs say: “Informs the workspace object that the file system changed at the specified path.” However, they also say: “Use of this method is discouraged.”

#5

Well this is beginning to interfere with users using the machines. They open windows, don’t see icons and call for help or give up. Here’s what I’m going to try: Open each directory in the Finder that filemanager touches when it’s done; run the Update command in the Finder (and see if any of these have custom icons); maybe this cocoa command (how would that look in a script?

#6 
current application's NSWorkspace's sharedWorkspace()'s noteFileSystemChanged:"/path/to/changed/stuff"

You should also include a use framework "AppKit" statement. Just which path or paths you use, you’re going to have to try by experimenting.

#7

Generates this error message:
+[NSWorkspace noteFileSystemChanged:]: unrecognized selector sent to class 0x7fff75147a68

#8

My mistake — see the amended code above.

#9

Adding the finder’s update command seem to help reduce the time the windows stall before populating. I’ll try your amended version next

Thanks!

#10

So this worked. I’m still toying with it but my initial impressions seem to be without the update, the stalls in displaying folder contents could last 30 to > 120 seconds. With the handler <10 seconds. It also seems that if I use the finder update by itself the stalls are about 20 seconds; if I use Shane’s command the same. Using both seem to work consistently better.

use framework "AppKit"

on UpdateDirectory(directoryToUpdate)
   local directoryToUpdate, directoryToUpdatePosix
   try
      set directoryToUpdatePosix to POSIX path of directoryToUpdate
      current application's NSWorkspace's sharedWorkspace()'s noteFileSystemChanged:directoryToUpdatePosix
      tell application "Finder"
         update (directoryToUpdate as alias) ¬
            necessity false ¬
            without registering applications
      end tell
   on error errMsg number errNum
      errMsg
   end try
end UpdateDirectory
#11

Boring feature.
If the folder triggered by the script was given a custom icon, this one is removed exactly as it is when we call the Finder’s update command.

Yvan KOENIG running High Sierra 10.13.6 in French (VALLAURIS, France) dimanche 25 novembre 2018 16:16:31

#12

That’s not an issue for me so minimizing (but not eliminating) the stall is not worth it. (This hander uses both AObjC and the FInder’s update)

How would you resolve the issue? The stalls didn’t happen when using Finder or System Events to manage files, but the scripts took 10 times longer to run.

#13

I’m assuming you’re managing a bucket load of files. It may well be that you’re hitting the law of free lunches. But it might also be worth trying your update code in multiple places, such as in subfolders first. It might not help, but you won’t really know until you try it (which you might have already).

#14

I’m almost ready to call this issue solved, but I’m wondering if anyone else has had this experience. It’s hit both my macs at home and several macs at work after I upgraded from finder/system event calls for file management to File Manager Lib.

As for subfolders, yes, I’m still experiencing longer stalls in cases where:
A folder containing subfolder is copied. I update the destination directory, but I also need to update the folder in its new destination and any subfolders.

I may change the handler I posted earlier to recusively get a list of all folders inside and update those.

#15

Not a lot of files. One folder has a dozen items including folders with 2 items; 3 items; 21 items. Another folder has 28 text files. Another Another has 14 files and a subfolder with several hundred files (1 for each day of the year so far) and sub folders going back years each with one file for each day).

The one with the longest delay was the first, which is also the most important and most used.

The most noticeable stall is for

#16

So this issue has returned and slowly gets worse. The macs get to the point where they’re unusable. Plus, the new scripts were installed on a mac that had been running fine, and is now experiencing the same stalls.

Restarting in Safe Mode helps, but when the issue comes back when we restart in normal mode.

I’m going to remove the ASObjC command in the handler above and just use the Finder’s update command. If that doesn’t work I’ll have to drop File Manager, which is a shame because other than this one issue it’s much faster and stable than Finder.