Windows: Navigation pane entries are removed at every client startup and never re-created (registry update runs before folders are loaded)

[Hotziplotzi]

⚠️ Before submitting, please verify the following: ⚠️

• This is a bug, not a question or a configuration issue.
• This issue is not already reported on Github (I have searched for it).
• Nextcloud Server and Desktop Client are up to date. See Server Maintenance and Release Schedule and Desktop Releases for supported versions.
• I agree to follow Nextcloud's Code of Conduct

Bug description

Description

On Windows, the Explorer navigation pane entries for synced folders ("Show sync folders in the Explorer navigation pane" = enabled) are removed at every client startup and never written back. The Nextcloud folder disappears from the Explorer navigation pane after each Windows reboot / client restart, even though the setting is enabled and the client is running.

Environment

• Client version: 34.0.3 (build 20260826)
• Operating system: Windows 11 Version 25H2
• Sync folder: C:\Users\<user>\Nextcloud (classic sync, no virtual files / VFS)
• Toggle showInExplorerNavigationPane=true in nextcloud.cfg (persisted, unchanged across restarts)
• The folder's navigationPaneClsid is persisted in next.cfg (0\Folders\1\navigationPaneClsid=…) and does not change across restarts.

Actual behavior

The client deletes its existing namespace entries at startup but never re-creates them.

Client log (%APPDATA%\Nextcloud\logs\…_nextcloud.log.0.gz, complete startup session, 22k+ lines):

14:54:12.173 [ info nextcloud.gui.folder.navigationpane …\navigationpanehelper.cpp:161 ]:
    Explorer Cloud storage provider: now unused, removing own CLSID "{16f4a9d0-1df9-4035-adbf-dcba2381e791}"

That is the only navigationpane log line of the whole session. There is no
Explorer Cloud storage provider: saving path … to CLSID … line, i.e. updateCloudStorageRegistry()
performed the removal pass but never reached the save pass.

Registry state after client startup (HKCU):

• Software\Microsoft\Windows\CurrentVersion\Explorer\Desktop\NameSpace\{…} – missing (was removed)
• Software\Classes\CLSID\{…} – orphaned leftover of an older GUID generation (no namespace link)

Root cause analysis

In src/gui/navigationpanehelper.cpp:

1. The NavigationPaneHelper constructor schedules an initial
   updateCloudStorageRegistry() run ("Ensure that the folder integration stays persistent in
   Explorer, the uninstaller removes the folder upon updating the client.").
2. updateCloudStorageRegistry() walks all Desktop\NameSpace sub keys and marks every entry
   with a matching ApplicationName for removal, then re-saves only the folders currently present
   in FolderMan's folder map:
   for (const auto &folder : _folderMan->map()) { if (!folder->navigationPaneClsid().isNull()) … }
3. At client startup the scheduled run fires before the folders are loaded into
   FolderMan's map (accounts/folders are restored asynchronously). The removal pass therefore
   deletes the old entries, the save loop iterates over an empty folder map and writes nothing.
   The 500 ms single-shot timer is never re-armed afterwards, so the entries are never restored.

This matches the log exactly: one "removing own CLSID" line, zero "saving path" lines.

Suggested fix

One of the following:

• Re-schedule after folders are loaded: call
  NavigationPaneHelper::scheduleUpdateCloudStorageRegistry() once FolderMan has finished
  loading/restoring the folder list (e.g. at the end of FolderMan::setupFolders() /
  after accounts are restored), instead of (or in addition to) scheduling it in the constructor.
• Guard the removal pass: in updateCloudStorageRegistry(), skip the removal of existing
  entries when _folderMan->map() is empty (folders not yet loaded) and re-schedule the update
  instead of performing a destructive pass with incomplete state.

Workaround (what we use meanwhile)

A PowerShell script that reads the per-folder navigationPaneClsid from nextcloud.cfg
(QSettings @Variant QUuid blob), re-creates the full MSDN "Cloud storage provider – navigation
pane" registry set (steps 1–12, incl. Wow6432Node and HideDesktopIcons) for exactly that CLSID,
and sends SHChangeNotify(SHCNE_ASSOCCHANGED) so the running Explorer picks it up.

Note: registering the config-persisted CLSID is what makes the workaround durable – the
client's startup cleanup only removes entries whose GUID does not match a folder's persisted
navigationPaneClsid. Also worth mentioning: the client never calls SHChangeNotify, so even
when the entries are written correctly, a running Explorer instance only shows them after a
restart of the Explorer process (or an external SHChangeNotify).

Additional context

• The behavior is 100 % reproducible on this machine across multiple reboots.
• Toggling the setting off/on "fixes" it temporarily because that path runs
  updateCloudStorageRegistry() while the folder map is populated.

Steps to reproduce

Steps to reproduce

1. Enable "Show sync folder in Explorer navigation pane" in the client settings.
2. Verify the folder is visible in the Explorer navigation pane.
3. Reboot Windows (or exit and restart the client).
4. Open Explorer → the Nextcloud entry is gone.

Expected behavior

Expected behavior

After client startup with the toggle enabled, the Desktop\NameSpace and CLSID registry entries for the sync folder exist and the folder is visible in the Explorer navigation pane.

Which files are affected by this bug

src/gui/navigationpanehelper.cpp and src/gui/folderman.cpp

Operating system

Windows

Which version of the operating system you are running.

Windows 11 25H2

Installation method

Official Linux AppImage

Nextcloud Server version

33.0.8

Nextcloud Desktop Client version

34.0.3

Did this occur after an update or on a clean installation?

Minor version update (i.e. 33.0.0 → 33.0.1)

Are you using the Nextcloud Server Encryption module?

No

Are you using an external user-backend?

• Default internal user-backend
• LDAP or Active Directory
• SSO - SAML
• Other

Nextcloud Server logs

Additional info

No response