System Settings
→ Network
→ Wi-Fi (or Ethernet)
→ Details
→ TCP/IP
→ Configure IPv6
→ Link-Local Only

dig client.dropbox.com
dig api.dropboxapi.com

GFiber
↓
Dropbox Edge A

VPN
↓
Dropbox Edge B

nettop -m tcp

lsof -i

SYN_SENT

ESTABLISHED

log stream --predicate 'process == "Finder" OR process == "fileproviderd"' --style compact

sudo tcpdump -i en0 host dropbox.com

scutil --dns

dig client.dropbox.com
dig api.dropboxapi.com
dig notify.dropboxapi.com

time mv ~/Desktop/testfile ~/Dropbox/

ls -l ~/Dropbox/testfile

Finder
    │
    ├─ Starts move
    │
    ├─ Dropbox immediately notices the new item
    │      ↓
    │   "Syncing..."
    │
    └─ Finder continues showing
       "Preparing to move..." (~32 s)

time cp -R ~/Desktop/TestFolder ~/Dropbox/

log stream --style compact --predicate 'process == "fileproviderd"'

cp -R ...

Desktop
└── Test
    └── hello.txt

FolderA     (fast)
FolderB     (slow)

xattr -lr FolderA

xattr -lr FolderB

New Folder
└── hello.txt

cp -R Test Test2

ditto Test Test2

ls -lO@

stat -x "Folder Name"

log stream --style compact --predicate 'process == "fileproviderd"'

enumerating from change 0 failed: NSError: FP -1002

No provider found with identifier (null)
getDomainsForProviderIdentifier((null)) failed

date
log stream --style compact --info --debug \
  --predicate '
    process == "Finder" OR
    process == "fileproviderd" OR
    subsystem CONTAINS[c] "FileProvider" OR
    senderImagePath CONTAINS[c] "Dropbox"
  '

Prompt (Jul 14 #7):

ID: 20260714093642

This capture gives us a much clearer result:

The 21-second delay occurred before fileproviderd became involved

You started the logging command at 09:53:41, but the first File Provider event did not occur until 09:54:08.590.

Once fileproviderd began processing the operation, it moved very quickly:

• destination folder detected at 09:54:08.640;
• Dropbox create operation completed in about 133 ms;
• the copied subfolder completed in about 39 ms;
• the 1.64 MB PDF content was fetched locally in about 19 ms.

The entire visible fileproviderd sequence runs only from 09:54:08.590 through 09:54:13.578—about five seconds—and there is no multi-second blocking request inside it.

What this means

The Finder “Preparing to move…” phase is almost certainly occurring before Finder commits the filesystem changes to the Dropbox File Provider location.

The likely timeline is:

Finder begins operation
        │
        │   approximately 20–21 seconds
        │   "Preparing to move..."
        │   no fileproviderd activity
        ▼
Finder finally creates destination items
        │
        ▼
fileproviderd detects them at 09:54:08.640
        │
        ▼
Dropbox processes and uploads them normally

That changes the diagnosis significantly. The principal delay is not:

• uploading the 1.7 MB;
• Dropbox transferring file contents;
• File Provider waiting for Dropbox server acknowledgement;
• File Provider enumerating the destination after receiving the files.

The delay is in a Finder-side preflight or coordination step before the handoff.

The errors are probably secondary

The capture again contains:

No provider found with identifier (null)
getDomainsForProviderIdentifier((null)) failed

and an XPC client connects and immediately exits.

It also reports:

Next pending set checking arrives too soon ... likely under load

followed by many enumerators.

Those indicate somewhat messy File Provider activity, but they occur after the apparent 21-second delay. They therefore cannot by themselves explain the initial Preparing interval.

The next trace needs Finder and the Dropbox extension

Filtering only on fileproviderd excludes the component that is apparently waiting. Use this instead:

date
log stream --style compact --info --debug \
  --predicate '
    process == "Finder" OR
    process == "fileproviderd" OR
    process CONTAINS[c] "Dropbox" OR
    senderImagePath CONTAINS[c] "Dropbox" OR
    subsystem CONTAINS[c] "FileProvider" OR
    subsystem CONTAINS[c] "filecoordination"
  '

Start the move immediately after running it, and stop five seconds after the Preparing dialog disappears.

To make the timing unambiguous, execute this in a second Terminal window at the precise moment you release the dragged folder:

date "+MOVE START %Y-%m-%d %H:%M:%S.%3N"

macOS date may not support %3N; this alternative always works:

python3 -c 'import datetime; print("MOVE START", datetime.datetime.now().isoformat(timespec="milliseconds"))'

Then run the same command when the dialog disappears, replacing MOVE START with MOVE END.

Current conclusion

This second log strongly supports:

Finder spends roughly 20 seconds preparing or coordinating the operation before any destination mutation reaches Dropbox’s File Provider domain.

Because VPN use removes that delay, Finder’s preflight likely invokes either:

• the Dropbox File Provider extension process directly;
• a system network or trust service;
• a Finder extension supplied by Dropbox;
• or another process that is not named fileproviderd.

The broader trace should reveal which process owns those missing 20 seconds.

Prompt (Jul 14 #8):

Here’s request log, started before start moving a folder and let it run some seconds after finished. Move in this case was rather fast so tried another folder (also move), also fast. Rather lengthly log.

Pasted text(2).txt
Document

ID: 20260714095440

This is useful as a working/fast baseline, even though neither operation reproduced the full 20–50 second problem.

What happened in this capture

First move

Finder displayed or loaded the “Preparing to move…” progress state at 09:59:54.424.

At 09:59:59.807, Finder recorded the move result and filecoordinationd received the completed move hint. That puts this operation’s visible preparing/coordination interval at roughly 5.38 seconds.

So, although this felt comparatively fast, it was not instantaneous. Finder still spent over five seconds in its copy/move machinery.

Second operation

The second operation is logged as “Preparing to duplicate…”, beginning at 10:00:09.857. Interestingly, immediately before that, Dropbox and OneDrive both performed File Provider pending-item rescans.

The drag completed at 10:00:13.254, making this interval about 3.40 seconds.

Important comparison with the slow case

The fast baseline gives us approximate Finder-side preparation times of:

That means the problematic behavior is likely not a completely different code path. Finder appears to perform the same preparation work every time, but sometimes one step takes far longer.

A particularly interesting clue

The first operation ends with:

Received item move hint with purpose com.apple.desktopservices.copyengine

This identifies Apple’s DesktopServices copy engine as the Finder component managing the operation—not Dropbox’s upload engine.

Dropbox File Provider reconciliation is already active at that same moment, but it does not show a long request or timeout. This reinforces the conclusion that the dialog is controlled by Finder/DesktopServices while it:

• enumerates the folder;
• checks destination capabilities;
• prepares file-coordination claims;
• calculates operation details;
• queries File Provider item status.

Another unexpected finding

Your system currently has at least three non-Apple File Provider domains active:

• Dropbox
• Google Drive
• OneDrive

At the beginning of the capture, Google Drive and OneDrive are each performing repeated full rescans for pending items, apparently once per second.

Immediately before the second operation, OneDrive and Dropbox also perform full pending-item rescans.

This does not prove that Google Drive or OneDrive causes the Dropbox delays. The moves were fast in this trace despite those rescans. But it does show that fileproviderd is managing multiple active providers and doing substantial background work.

A worthwhile isolation test is therefore:

1. Fully quit Google Drive.
2. Fully quit OneDrive.
3. Leave Dropbox running.
4. Restart Finder:

killall Finder

5. Repeat ten or more local-to-Dropbox Finder moves over raw GFiber.

That is now more useful than testing file metadata or file size.

One correction to the earlier interpretation

The presence of text such as:

Preparing to move…

in the log does not necessarily mean that the dialog remained visibly onscreen for the entire measured period. Finder loads those localized strings when constructing or updating the progress window.

Still, the timestamps around the copy-engine completion give a reasonable upper bound:

• about 5.4 seconds for the first operation;
• about 3.4 seconds for the second.

Best next capture

The broad debug trace produces almost 90,000 lines in 34 seconds, mainly irrelevant Finder icon and Launch Services messages. A narrower predicate should retain the useful copy-engine and File Provider events:

log stream --style compact --info --debug \
  --predicate '
    subsystem == "com.apple.DesktopServices" OR
    subsystem CONTAINS[c] "filecoordination" OR
    subsystem CONTAINS[c] "FileProvider" OR
    process == "DropboxFileProvider"
  '

The most useful next evidence will be a trace in which the delay actually lasts 20+ seconds. We can then compare exactly which claim or DesktopServices operation remains open between the fast baseline and slow case.

Prompt (Jul 14 #9):

I figured out that I both had OneDrive running and was able to quit it. But, can’t either see any signs of Google Drive running nor any app to stop/use for configuration. Why do you claim I got that running?

ID: 20260714100112

Good catch. I overstated that conclusion.

What the log actually shows is not that the Google Drive application is running. It only shows that there are File Provider domains active for Dropbox and OneDrive in the excerpts I reviewed.

Looking back, I inadvertently conflated previous conversations about your Google Drive usage with this log. In the excerpts from this capture I can actually support:

• Dropbox File Provider:

  com.getdropbox.dropbox.fileprovider

• OneDrive File Provider:

  com.microsoft.OneDrive-mac.FileProvider

I cannot support a claim from this log that Google Drive is currently active.

Since you were able to quit OneDrive, that’s a worthwhile test because it removes one File Provider extension from the system.

If you don’t see:

• Google Drive.app
• Google Drive in the menu bar
• a LaunchAgent for Google Drive
• a ~/Library/CloudStorage/GoogleDrive* folder

then it very likely is not currently installed or running.

A quick check from Terminal:

pgrep -ifl "Google Drive|GoogleDrive|drivefs"

and

ls ~/Library/CloudStorage

If neither shows Google Drive, then we can eliminate it entirely.

What I’d recommend now is:

1. Leave OneDrive quit.
2. Leave Dropbox running.
3. Repeat the same Finder move that sometimes takes 20–50 seconds.
4. If the delay disappears consistently, OneDrive’s File Provider extension may have been contributing to contention inside fileproviderd.
5. If the delay remains unchanged, we can rule OneDrive out and continue looking at Finder/DesktopServices and Dropbox specifically.

This isolation test is much cleaner now that OneDrive has been removed from the equation.

Prompt (Jul 14 #10):

Last login: Tue Jul 14 09:08:59 on ttys009
You have mail.

The default interactive shell is now zsh.
To update your account to use zsh, please run chsh -s /bin/zsh.
For more details, please visit https://support.apple.com/kb/HT208050.
MB2314:~ johan$ pgrep -ifl “Google Drive|GoogleDrive|drivefs”
MB2314:~ johan$ ls ~/Library/CloudStorage Dropbox OneDrive-Personal GoogleDrive-johan.sarkinen@gmail.com
MB2314:~ johan$ ls -l ~/Library/CloudStorage
total 0
drwx——@ 33 johan staff 1056 Jul 13 17:07 Dropbox
drwx——@ 6 johan staff 192 May 22 06:58 GoogleDrive-johan.sarkinen@gmail.com
drwx——@ 31 johan staff 992 Jun 22 06:43 OneDrive-Personal
MB2314:~ johan$

ID: 20260714100635

Ah! That’s actually very interesting.

The important observation is this:

~/Library/CloudStorage/
    Dropbox
    GoogleDrive-johan.sarkinen@gmail.com
    OneDrive-Personal

but

pgrep -ifl "Google Drive|GoogleDrive|drivefs"

returned nothing.

That means Google Drive is almost certainly not running

The folder remains because it’s a File Provider domain that was previously created.

macOS does not automatically remove ~/Library/CloudStorage/GoogleDrive-... just because the application isn’t running (or even installed).

So I would now regard Google Drive as inactive and not part of the current problem.

OneDrive is a bit more interesting

Before you quit it, OneDrive was appearing inside fileproviderd.

After quitting it, I’d expect those messages to disappear from the logs.

So we’ve reduced the system to essentially:

• Finder
• fileproviderd
• Dropbox File Provider

That’s a much cleaner environment.

One thing I now want to investigate

There is something that’s been nagging me since your VPN discovery.

Finder does not normally perform long network operations itself.

Instead, it uses:

Finder
   ↓
DesktopServices copy engine
   ↓
filecoordinationd
   ↓
fileproviderd
   ↓
Dropbox File Provider

Your logs clearly show the DesktopServices copy engine involved.

The mystery is:

What is DesktopServices waiting for during those extra 20–40 seconds?

I’d like to compare the network itself

Since the VPN completely changes the behavior, I think it’s time to look at Dropbox’s connections.

Could you run, while reproducing a slow move, this in another Terminal?

lsof -i -n -P | egrep 'Dropbox|fileproviderd|Finder'

or, even better:

nettop -m tcp

I’m interested in seeing whether fileproviderd or a Dropbox helper process has one TCP connection that sits idle during the “Preparing…” dialog.

One more thing I noticed

Your CloudStorage directory timestamps are:

Dropbox               Jul 13
Google Drive          May 22
OneDrive              Jun 22

Google Drive hasn’t touched its CloudStorage folder in almost two months.

That further supports that it’s inactive.

I have one suspicion that has grown stronger

You originally mentioned:

This started around macOS 26.4.

The logs don’t show Dropbox taking 20 seconds.

Instead they show Finder spending time in DesktopServices before File Provider gets busy.

That increasingly resembles an Apple regression rather than a Dropbox regression.

The VPN makes it confusing, but it may simply be changing how quickly Dropbox’s File Provider answers one particular metadata request.

One experiment I think could be decisive

Instead of using Finder, use Apple’s own file copy tool:

ditto "/path/to/source" "/Users/johan/Library/CloudStorage/Dropbox/Test"

You’ve already shown that mv is fast.

I’d like to know whether ditto is also always fast.

If:

• mv → instant
• ditto → instant
• Finder → sometimes 30 seconds

then we’ve essentially proven the problem is in Finder/DesktopServices rather than the underlying filesystem or Dropbox.

At that point, I would seriously consider filing a Feedback Assistant report with Apple, because your logs are increasingly pointing toward Finder’s copy engine rather than Dropbox’s sync engine. I don’t say that lightly—I usually prefer exhausting application-level explanations first, but you’ve been methodically eliminating them.

Prompt (Jul 14 #11):

ditto also happens instantaneous

ID: 20260714101328

That’s actually one of the strongest pieces of evidence you’ve found so far.

Let’s summarize everything you’ve established:

This is becoming a very specific problem.

What this proves

The filesystem itself is not the bottleneck.

The Dropbox File Provider itself is probably not the bottleneck either.

If it were, then ditto would have to wait too, because it writes into exactly the same Dropbox-managed directory.

Instead:

ditto
    ↓
APFS
    ↓
Dropbox File Provider

works immediately.

Whereas:

Finder
    ↓
DesktopServices Copy Engine
    ↓
NSFileCoordinator
    ↓
FileProvider

sometimes pauses for tens of seconds.

That narrows it dramatically.

I now think the culprit is Finder’s Copy Engine

The logs repeatedly identify:

com.apple.desktopservices.copyengine

That’s the internal Finder component responsible for drag-and-drop copy/move operations.

Notice something else:

• Finder drag/drop → slow
• Finder Duplicate → sometimes slow
• Terminal → never slow

That is exactly what you’d expect if DesktopServices is the component waiting.

But why does the VPN matter?

This is still the million-dollar question.

There are only a few possibilities left.

1. Finder is waiting on a Dropbox metadata request

Not the upload.

Not the file write.

A metadata/API request.

VPN changes:

• destination IP
• routing
• DNS
• Dropbox edge server

and therefore eliminates the wait.

2. Finder is waiting on an Apple framework

DesktopServices may be calling File Provider through XPC and waiting on an acknowledgment that itself depends on Dropbox networking.

The logs suggest this chain more than direct Dropbox delays.

I think we’ve reached the point where we should stop guessing.

I’d like to know what Finder is waiting for, not infer it.

The best tool now is Apple’s sample utility.

When Finder is sitting on:

Preparing to move…

open another Terminal and run:

sample Finder 10

or even:

sudo sample Finder 10

This captures ten seconds of Finder’s stack traces.

If Finder spends those ten seconds inside:

• NSFileCoordinator
• DesktopServices
• File Provider
• XPC
• a network wait

we’ll know exactly.

I’d also sample fileproviderd simultaneously

In another Terminal:

sample fileproviderd 10

Now we’ll have:

• what Finder is blocked on
• what File Provider is doing

during the exact same 10-second interval.

This is much more powerful than the unified log because it shows where the threads are actually sleeping.

My confidence ranking has shifted

At this point I’d estimate:

70% Finder/DesktopServices regression introduced around macOS 26.4

20% Interaction with Dropbox File Provider over a particular network path

10% Something else (DNS, routing, trust services, etc.)

One final observation

Your experiments have been unusually systematic, and that’s why we’re getting somewhere.

Most people stop at “Dropbox is slow.”

You’ve demonstrated:

• same destination,
• same files,
• same machine,
• same Dropbox,
• same filesystem,

but changing only the client implementation (Finder vs. ditto) changes the behavior completely.

That strongly indicates the problem lives above the filesystem and below Finder’s UI, almost exactly where com.apple.desktopservices.copyengine operates.

I think sample is now the highest-value diagnostic we can run. If Finder is blocked in DesktopServices or NSFileCoordinator for those 20–50 seconds, it will show up unmistakably in the stack traces.

Prompt (Jul 14 #12):

So, exactly what test do you want me to run now then?

ID: 20260714101855

I think we’re at the point where we should stop collecting more log stream output. It has been useful, but it isn’t showing us what Finder is waiting for. It only shows what components are logging.

The single most valuable test now is to capture Finder’s call stacks while it is stuck.

Test 1 (highest priority): Sample Finder while it’s stuck

1. Reproduce the problem until you get a 20–50 second “Preparing to move…” dialog.
2. Do not cancel it. Leave it sitting there.
3. Open Terminal and run:

sample Finder 10

If sample says it can’t attach, use:

sudo sample Finder 10

4. Wait until it finishes (10 seconds).
5. Save the output to a file:

sample Finder 10 > ~/Desktop/FinderSample.txt

(or with sudo if needed)

Test 2 (same time): Sample fileproviderd

While Finder is still sitting on “Preparing…”:

sample fileproviderd 10 > ~/Desktop/fileproviderdSample.txt

Again, use sudo if required.

Why this is different

log stream tells us:

“Finder called X.”

sample tells us:

“Finder has been sitting in this exact function for the last 10 seconds.”

That’s the information we’re currently missing.

Optional (but useful)

Immediately after the delay finishes, run:

spindump Finder -onlyTarget -duration 5

or

sudo spindump Finder -onlyTarget -duration 5

This is even more detailed than sample, but usually sample is sufficient.

What I’m looking for

If the hypothesis is correct, Finder will be spending most of those 10 seconds inside something like:

• DesktopServices
• NSFileCoordinator
• NSFileProvider
• dispatch_semaphore_wait
• xpc_connection_send_message_with_reply_sync
• mach_msg
• __psynch_cvwait

Those names would tell us what it’s waiting on.

If sample doesn’t work

Tell me exactly what macOS 26.4 reports.

Apple has moved some developer tools around in recent releases. If necessary, we’ll use:

spindump

or

sample Finder -file ~/Desktop/FinderSample.txt 10

depending on what’s available.

Why I think this is the right next step

At this stage we’ve already proven:

• ✔ Not the filesystem
• ✔ Not APFS
• ✔ Not file size
• ✔ Not Terminal
• ✔ Not ditto
• ✔ Probably not Dropbox upload
• ✔ Probably not fileproviderd itself

The missing piece is simply:

What is Finder’s DesktopServices copy engine waiting for during those 20–50 seconds?

A sample taken while the dialog is visible has the best chance of answering that directly. I think it has a much higher diagnostic value than another round of unified logging.

Prompt (Jul 14 #13):

<simply pasted text copied from a terminal window>

sudo spindump Finder -onlyTarget -duration 10

sample Finder 20

Prompt (Jul 14 #14):

Deleting a folder now took 33 seconds

TDesktopServicesHelperCopyMoveOperation::PerformMove
→ TNode::Move
→ NSFileCoordinator coordinateWritingItemAtURL...
→ _blockOnAccessClaim
→ dispatch_semaphore_wait

Finder/DesktopServices
        ↓
requests coordinated move
        ↓
NSFileCoordinator
        ↓
waits for another participant to release or approve the claim
        ↓
33-second delay

TDesktopServicesHelperCopyMoveOperation::ResolveConflict
TDesktopServicesHelperCopyMoveOperation::PerformMove
TNode::Move
NSFileCoordinator coordinateWritingItemAtURL...
_blockOnAccessClaim
_dispatch_semaphore_wait_slow

sample filecoordinationd 15 > ~/Desktop/filecoordinationd-slow.txt

sample fileproviderd 15 > ~/Desktop/fileproviderd-slow.txt

sample DropboxFileProvider 15 > ~/Desktop/DropboxFileProvider-slow.txt

Prompt (Jul 14 #15):

MB2314:~ johan$ sample filecoordinationd 15 > ~/Desktop/filecoordinationd-slow.txt sample[15044]: sample cannot find any existing process you have access to which has a name like ‘filecoordinationd’; try running with sudo. MB2314:~ johan$ MB2314:~ johan$ sample fileproviderd 15 > ~/Desktop/fileproviderd-slow.txt Sampling process 88502 for 15 seconds with 1 millisecond of run time between samples Sampling completed, processing symbols… Sample analysis of process 88502 written to file /tmp/fileproviderd_2026-07-14_110336_lCRO.sample.txt MB2314:~ johan$ MB2314:~ johan$ sample DropboxFileProvider 15 > ~/Desktop/DropboxFileProvider-slow.txt Sampling process 8313 for 15 seconds with 1 millisecond of run time between samples Sampling completed, processing symbols… Sample analysis of process 8313 written to file /tmp/DropboxFileProvider_2026-07-14_110337_uRvt.sample.txt MB2314:~ johan$

sudo sample filecoordinationd 15 > ~/Desktop/filecoordinationd-slow.txt

FPDFilePresenter _fetchChangeToken
→ FPDFilePresenter enumerator
→ dispatch_group_wait

sqlite3_step
→ sqlite3VdbeExec
→ sqlite3Btree...
→ readDbPage
→ pread

Finder
  waits for NSFileCoordinator claim
      ↓
fileproviderd
  waits for Dropbox enumerator/change-token state
      ↓
fileproviderd performs a long query against its local
Dropbox File Provider metadata database

killall Finder
killall DropboxFileProvider

sudo killall fileproviderd

sudo sample filecoordinationd 15 > ~/Desktop/filecoordinationd-slow.txt

Prompt (Jul 14 #16):

The default interactive shell is now zsh.
To update your account to use zsh, please run chsh -s /bin/zsh.
MB2314:~ johan$ sudo sample filecoordinationd 15 > ~/Desktop/filecoordinationd-slow.txt
Sampling process 729 for 15 seconds with 1 millisecond of run time between samples
Sampling completed, processing symbols…
Sample analysis of process 729 written to file /tmp/filecoordinationd_2026-07-14_112307_Q3fT.sample.txt
MB2314:~ johan$ mv /tmp/filecoordinationd_2026-07-14_112307_Q3fT.sample.txt ~/Downloads/
mv: rename /tmp/filecoordinationd_2026-07-14_112307_Q3fT.sample.txt to /Users/johan/Downloads/filecoordinationd_2026-07-14_112307_Q3fT.sample.txt: Permission denied
MB2314:~ johan$ sudo mv /tmp/filecoordinationd_2026-07-14_112307_Q3fT.sample.txt ~/Downloads/
MB2314:~ johan$

filecoordinationd_2026-07-14_112307_Q3fT.sample.txt
Document

Finder/DesktopServices
    waits for coordinated access
            ↓
filecoordinationd
    processes the claim normally
            ↓
fileproviderd
    waits for Dropbox enumeration/change-token state
    and spends most of the sample reading its local SQLite database
            ↓
DropboxFileProvider
    largely idle/waiting

sqlite3_step
→ sqlite3VdbeExec
→ B-tree page traversal
→ readDbPage
→ pread

killall Finder
killall DropboxFileProvider
sudo killall fileproviderd

sudo chown "$USER":staff ~/Downloads/filecoordinationd_2026-07-14_112307_Q3fT.sample.txt

Prompt (Jul 14 #17):

But the case of ON VPN still remains, i.e. problem does not show when on VPN. 

ID: 20260714113422

Correct — the VPN result means we cannot conclude this is merely a corrupt or slow local File Provider database.

The database activity we captured may be the place where the delay manifests, but the VPN result strongly suggests that the state causing that database/enumeration stall is network-dependent.

The more accurate chain is probably:

GFiber path
   ↓
Dropbox metadata/change notification behaves poorly or times out
   ↓
File Provider metadata state becomes stale or incomplete
   ↓
fileproviderd performs long enumeration/database reconciliation
   ↓
Finder’s coordinated move/delete waits

With VPN:

VPN route / DNS / source IP / Dropbox edge
   ↓
Dropbox metadata exchange completes normally
   ↓
File Provider state stays current
   ↓
Finder operation proceeds quickly

So the VPN finding remains central, not incidental.

The next test should compare the actual network environment

Do this once without VPN and once with VPN:

scutil --dns > ~/Desktop/dns-no-vpn.txt
route -n get default > ~/Desktop/route-no-vpn.txt
networkQuality -v > ~/Desktop/network-no-vpn.txt

Then connect the VPN and run:

scutil --dns > ~/Desktop/dns-vpn.txt
route -n get default > ~/Desktop/route-vpn.txt
networkQuality -v > ~/Desktop/network-vpn.txt

The DNS comparison is especially important because the VPN may send Dropbox hostname lookups to different addresses or regions.

Most decisive live test

While reproducing one slow Finder operation without VPN, run:

sudo nettop -P -m tcp -J state,interface,rx_dupe,rx_ooo,re-tx,conn_attempts,time -p DropboxFileProvider

If that process name does not work with nettop, use:

sudo nettop -P -m tcp

Watch for connections belonging to:

• DropboxFileProvider
• Dropbox
• fileproviderd

We are looking for:

• repeated connection attempts;
• retransmissions;
• a connection stuck during the 20–50 second interval;
• a different destination when VPN is enabled.

A simpler controlled test: DNS only

Before changing anything else, temporarily use a different DNS resolver on the raw GFiber connection, such as:

1.1.1.1
1.0.0.1

Then repeat several Finder operations.

Interpretation:

• Problem disappears: likely GFiber DNS or the Dropbox edge selected through that DNS.
• Problem remains: routing, peering, MTU, packet loss, or source-IP-specific Dropbox behavior becomes more likely.
• Problem disappears only with VPN: the route or Dropbox edge is more likely than DNS alone.

Current diagnosis

The evidence now supports two layers:

1. Immediate blocking point: Finder waits on File Coordination while fileproviderd reconciles Dropbox metadata.
2. Underlying trigger: something about the raw GFiber network path causes that Dropbox/File Provider metadata state to become slow or stale.

The local database behavior is therefore probably a symptom, not necessarily the original cause.