Does Find now run asynchronously?

[lxp]

If so, I seem to have missed the news (and can't find it in the docs or the forum).

I stumbled upon this here and it could be the explanation for why FindDupesInSubfolders does not work anymore.

When FDIS is run on just a few folders, they'll get quickly enumerated, the command lines get generated and started and then the script finishes, abandoning almost all Find dialogs which will keep spinning endlessly.

Prefixing Find with @sync seems to kill the Find dialogs without getting results back.

[Wombat]

I'm pretty sure FIND has always been asynchronous. I asked about this a few months back when it was clear that its behaviour did not match what the docs said.

[Leo]

@lxp

I stumbled upon this here

What I said there turned out to be incorrect. (With a different explanation for why it didn't work as expected.) Details here:

Find Sync example doesn't actually compare or sync

Try adding RECURSE to the first line: Find SYNC FROM "D:\Work" TO "D:\Backups" RECURSE COMPARE=newer HIDEUNAFFECTED Copy SYNC Set CLEARSYNC That was missing from the example but would usually be wanted with sync, so I'll add that to the docs. It's…

[Leo]

As far as normal Finds go, it seems to be synchronous, from a very quick test:

Find IN "C:\" NAME=dopus* UAC=no
Help ABOUT

That will show the About dialog after the search finishes, rather than during the search.

I haven't tried it from a scripting context, but it should usually be the same.

[Wombat]

This is a thread from last year on the behaviour of FIND

Confused about synchronous internal comands

According to https://www.gpsoft.com.au/help/opus12/index.html#!Documents/Synchronous_and_Asynchronous_functions.htm Internal commands always run synchronously - Opus will always wait for an internal command in a function to finish before moving on …

[lxp]

The abandoned dialogs were caused by using Find RUNINPANEL in the script. Without this parameter, Find is back to its normal behavior (whatever that may be ).