J&P
Sverige / USA
J&P

Preparing to …

Starting page for an issue that has been bugging me since beginning of April 2026, when upgraded to macOS 26.4.

Been busy and have had limited time to dig into detailed troubleshooting as problem does NOT show when on VPN.

Problem is can’t be on VPN all the time as banks, and a number of other sites for that matter, complaints and doesn’t work when detected on is using VPN… I.e. it’s sometimes a daily on-off switching of VPN use.

OWN SUMMARY

  1. ⚠️ On ‘raw’ GFiber, and GUI env. (macOS Finder): frequently getting “Preparing to move”… dialogs

    But dialogs can show up at all sorts of operations, as long as involving Finder, Dropbox, and ‘raw’ GFiber

    1. Copy or move files to AND from local volume to Dropbox-handled
    2. Deleting, moving to trash, items on Dropbox-handled area
  2. Never when
    1. Using command line interface (CLI) commands ✅, ONLY see problem when using graphical user interface (GUI, macOS Finder) ⚠️.
      1. There is something with Finder, Dropbox, and GFiber ⚠️
        1. Looks like something in Finder-Dropbox interactions/handshaking, but ONLY when ‘raw’ GFiber.
    2. ✅ On other WAN connection that ‘raw’ GFiber:
      1. NOT when use VPN on local computer, thus creating a tunnel over the GFiber network
      2. NOT when use cellular phone as hotspot
    3. ✅ in terminal (command line interface)

RESOURCES

 

FROM CHATGPT

See also chats mentioned above.  Below is merged from two documents created by ChatGPT – Engineering_Report_Finder_Dropbox_GFiber.docx (2026-07-14 16:59) and Engineering_Report_v2_Dropbox_Finder_GFiber.docx (2026-07-14 17:00).

1. Executive Summary

A reproducible Finder performance problem was investigated. The delay affects Finder operations into Dropbox-managed folders only when the Mac uses a direct Google Fiber Internet connection. The same Mac, Dropbox installation, and files work normally over a VPN using Google Fiber and over an unrelated cellular WAN. Command-line operations (mv, cp, ditto) are unaffected.

2. Environment

  1. macOS 26.4 and macOS 26.5 (25F71)
    1. Started after upgraded to 26.4: 2026-04-02 06.09.21 macOS Tahoe 26.4 Update
  2. Dropbox using Apple’s File Provider architecture
  3. Google Fiber primary ISP
  4. VPN over GFiber eliminates symptom
  5. Cellular hotspot also eliminates symptom

3. Symptom Characterization

Observed delays:

  1. E.g. PROBLEM: Local → Dropbox move: typically 20–50 s.
  2. E.g. PROBLEM: Delete of Dropbox folders: up to ~33 s.
  3. Delay independent of file size.
  4. Dropbox frequently reports ‘Syncing…’ while Finder still displays ‘Preparing…’.
  5. Terminal operations complete immediately. I.e.
    1. Command Line Interface (CLI) operations are always executing very fast, no delays.
    2. Graphical User Interface (GUI; macOS Finder): when problems is seen, dialog popping up for 20-50 seconds (showing (e.g.) Preparing to move… dialog)

4. Experiments Performed

  1. Little Snitch eliminated. (local, computer desktop, firewall)
  2. IPv6 disabled.
  3. DNS compared.
  4. MTU changed to 1420 (no effect).
  5. Finder/fileproviderd/filecoordinationd/DropboxFileProvider sampled.
  6. Unified logs collected.
  7. NetworkQuality compared.
  8. TCP sessions monitored.
  9. Dropbox DNS endpoints compared with and without VPN.

5. Findings

  1. Finder samples consistently showed waits inside DesktopServices/NSFileCoordinator.
  2. fileproviderd showed Dropbox metadata enumeration and SQLite activity.
  3. DropboxFileProvider appeared mostly idle during captured stalls.
  4. TCP captures showed established HTTPS sessions with no retransmissions or reconnect storms during the delay.
  5. DNS returned identical Dropbox endpoint IPs with and without VPN.

6. Eliminated Hypotheses

  1. Disk performance
  2. File size dependency
  3. Little Snitch
  4. Basic DNS latency
  5. MTU mismatch
  6. General Internet bandwidth
  7. Dropbox upload throughput
  8. APFS corruption

7. Remaining Hypotheses

A. Google Fiber routing/peering interaction with Dropbox control plane.
B. Dropbox backend behavior associated with the direct GFiber public IP.
C. Apple File Provider metadata reconciliation triggered by Dropbox state reached only on the direct GFiber path.
D. Finder/DesktopServices regression exposed only under this network condition.

8. Architectural Interpretation

Finder (DesktopServices copy engine)
↓
NSFileCoordinator
↓
filecoordinationd
↓
fileproviderd
↓
Dropbox File Provider
↓
Dropbox Cloud

The visible delay occurs while Finder waits for coordinated access. The captured evidence places the stall downstream of Finder but upstream of completion of File Provider coordination.

9. Why the VPN Matters

The VPN changes the network path and public identity while leaving the Dropbox application, filesystem and operating system unchanged. Because a cellular WAN also resolves the problem, the evidence points toward a direct-GFiber-specific interaction rather than a purely local software defect.

10. Recommended Engineering Actions

  1. Collect simultaneous packet captures on direct GFiber and VPN.
  2. Compare TLS sessions and long-lived notification connections.
  3. Investigate File Provider enumeration timing under identical workloads.
  4. Escalate to Dropbox engineering with stack samples.
  5. File Apple Feedback including Finder, fileproviderd and filecoordinationd samples.

11. Confidence Assessment

High confidence:
– Finder is waiting in coordinated file operations.
– CLI tools bypass the problematic path.
– Direct GFiber is a necessary condition.

Medium confidence:
– The trigger is network-path dependent rather than upload performance.

Open question:
– Which specific Dropbox control-plane interaction causes File Provider metadata reconciliation to stall only on the direct GFiber path?