Cloud Sync Is Stuck — Can You Delete the Cache? First Prove the Only Copy Is Not Sitting Inside It

Short answer: sometimes clearing a cache is safe, sometimes the provider explicitly supports it, and sometimes the cache contains the only copy of unsynced edits. The dangerous mistake is treating every cloud cache as disposable simply because the word cache sounds temporary.

Google Drive for desktop gives the clearest warning: when you use Stream files, unsynced changes can live in the local content cache, and Google explicitly says those changes can be lost if that cache is cleared or corrupted. By contrast, Microsoft documents a supported OneDrive reset that rebuilds sync connections without deleting your OneDrive data. Dropbox documents a manual cache-clearing procedure, but also says its cache acts as a staging area for uploads and downloads. Apple exposes supported actions such as Remove Download and status states such as Waiting to Upload, rather than telling users to manually delete File Provider internals. pCloud documents cache controls in the app, but does not publish a general consumer workflow that says to delete an internal cache directory by hand.

That is why the right question is not:

“Where is the cache folder?”

It is:

“Which bytes have already reached the cloud, and which bytes still exist only on this device?”

First separate three completely different kinds of local data

Cloud desktop clients can keep several local states that users casually call “cache.” They are not equally disposable.

The word cache only tells you that the client considers something local and managed. It does not prove that every byte is replaceable from the server.

This distinction is especially important with virtual-drive products. A file can appear in Finder or File Explorer while the actual content is cloud-only, locally cached, locally edited but not uploaded yet, or represented by a placeholder. The icon and sync state matter more than the path name.

If your broader problem is simply local disk pressure rather than a broken sync engine, use the provider's supported online-only or cache-size controls first. For pCloud specifically, pCloud Drive Cache Explained covers why its virtual drive still uses temporary local disk space.

Google Drive Stream mode is the strongest reason not to delete cache blindly

Google's current Drive for desktop advanced guide makes the risk unusually explicit.

With Stream files, files primarily live in the cloud and are materialized locally as needed. But if you make a change while the client cannot upload it yet, Google says the unsynced change is stored in the local cache. Google then states the critical consequence: those unsynced changes can be lost if the cache is cleared or corrupted.

That means this sequence can destroy data:

1. open a streamed file;
2. edit it offline or while Drive is failing to upload;
3. see Drive remain stuck;
4. assume the cache is disposable;
5. delete the Drive cache or its state directory;
6. reconnect and discover the cloud still contains the older version.

The problem is not that Google Drive “failed to back up the cache.” The problem is that the latest change never crossed the local-to-cloud boundary.

Google also warns users switching from Mirror to Stream to wait for recent changes to finish syncing before deleting the old mirrored folder. That is the same underlying safety principle: do not destroy local state until the remote state has been proven current.

Google Drive: safer order of operations

Before any cache reset or account reconnect:

1. open Drive for desktop and inspect activity/errors;
2. identify files with recent local edits;
3. check whether the newest version exists on drive.google.com;
4. copy any uncertain local file to a folder outside Drive for desktop;
5. only then use Google's supported reconnect/reset path;
6. after recovery, compare the local preserved copy with the remote copy before deleting either one.

If you cannot prove an edit reached the cloud, treat the local copy as irreplaceable until proven otherwise.

OneDrive reset is different: Microsoft actually documents it as a supported repair

OneDrive is a useful contrast because Microsoft publishes a formal Reset OneDrive procedure.

Microsoft says resetting OneDrive:

• resets OneDrive settings;
• disconnects existing sync connections;
• causes a full sync after setup;
• does not delete your OneDrive files or data.

That is a much stronger support statement than “delete some hidden cache directory and hope.”

Microsoft's older OneDrive for work or school Repair workflow exposes another safety principle: when it finds files with unsynced changes, it creates an archive copy of those files in a local folder before reconnecting and syncing the current server version.

That is exactly how a repair tool should behave when state is uncertain: preserve the uncommitted local version before rebuilding the sync relationship.

Use Files On-Demand to free space, not cache surgery

If your real problem is disk usage rather than a broken client, Microsoft already provides a supported state transition:

• Free up space converts locally available content back to online-only;
• Always keep on this device pins content locally.

Those actions operate through OneDrive's intended state model. They are safer than manually deleting hidden Files On-Demand or sync-state data.

A reset can still be disruptive because all connections have to rebuild and selective-sync choices may need to be reconfigured. But disruption is not the same thing as data loss, and Microsoft's documented reset path is fundamentally safer than arbitrary cache deletion.

Dropbox publishes a cache-clearing procedure — but the cache is also an upload/download staging area

Dropbox's current help article explicitly explains what .dropbox.cache is for.

It stores temporary files to improve performance and support uploads and downloads. Dropbox also says it functions as a staging area for downloading and uploading files. The cache normally clears itself, but Dropbox documents manual removal when needed.

The official procedure begins with an important prerequisite: fully quit the Dropbox desktop app. On File Provider setups, Dropbox also tells users to wait for the Dropbox File Provider extension process to stop before removing cache contents.

That support boundary matters.

Dropbox is not saying:

“Delete random internal files while sync is active.”

It is saying:

“If you need to clear the documented cache, stop the client first and use the documented location/procedure.”

Because the cache participates in transfers, CloudScope adds one conservative step before following even that official procedure: verify that recent important changes are visible on dropbox.com first. That extra step is our safety recommendation, not a quoted Dropbox requirement.

Dropbox also documents a separate condition that should stop you from doing destructive cleanup: if a folder contains unsyncable local files, deletion can become stuck. On Windows, some unsynced files can be moved to the Recycle Bin. That is evidence that “not present in the cloud” and “safe to discard locally” are not the same thing.

If you only need disk space, use Dropbox's supported online-only or selective sync features rather than treating .dropbox.cache as a general-purpose storage control.

iCloud Drive: “Waiting to Upload” means exactly what it says

Apple's Finder status documentation provides a useful hard boundary.

A file marked Waiting to Upload is not yet stored in iCloud.

That means any generic troubleshooting instruction that tells you to purge local File Provider state while files still show Waiting to Upload is operating on unverified data.

Apple gives users supported storage-state actions instead:

• Download Now for an item that is currently only in iCloud;
• Keep Downloaded to retain a local copy;
• Remove Download to remove the local downloaded copy while keeping the iCloud item;
• Finder status indicators to show transfer progress, downloaded state and cloud-only state.

The safe distinction is straightforward:

• In iCloud / Downloaded and up to date: there is documented evidence that the object exists remotely;
• Waiting to Upload: the latest local object has not yet reached iCloud;
• Out of Space: upload is blocked by quota, so the local item cannot be assumed to exist remotely.

Apple's public consumer documentation does not instruct ordinary users to delete hidden File Provider databases or caches as a general iCloud repair method. CloudScope therefore will not invent such a procedure.

If you need to reclaim local space, use Remove Download on files that are already in iCloud. If sync is broken, preserve Waiting-to-Upload files outside the iCloud-managed tree before making account-level changes.

pCloud: adjust the supported cache controls before touching internal files

pCloud Drive is a virtual drive, but it still uses local disk space as temporary cache during transfers. pCloud's current low-disk-space documentation explains that this cache helps with upload efficiency and unstable connections.

The supported response is not “find a hidden pCloud cache directory and delete it.” pCloud tells users to adjust:

Preferences / Settings → Disk Usage

and reduce the amount of disk space pCloud Drive may use for caching.

For very large uploads, pCloud also recommends using its Upload feature instead of copying and pasting large files directly into pCloud Drive, because that path does not rely on the same local caching behavior.

That gives us a clear evidence boundary:

• Documented fact: pCloud Drive uses temporary local cache during transfers;
• Documented fact: the cache size can be adjusted through app settings;
• Documented fact: Upload can be preferable for large transfers under local disk pressure;
• Not documented as a standard consumer fix: manually deleting an internal pCloud cache directory while transfer state is uncertain.

pCloud Sync is also a different architecture from pCloud Drive. Sync maintains a real local mirrored folder and reflects changes both ways. Deleting the local Sync copy is therefore not equivalent to evicting a replaceable virtual-drive cache item.

That distinction is important enough to repeat: Drive cache and Sync data are not the same thing.

The five-provider safety matrix

Notice what is not in this table: a universal path such as ~/Library/.../Cache that you can safely delete for every product.

That path does not exist because the products do not share one storage model.

A green check mark is evidence — but confirm the right file

Even before clearing a documented cache, check the actual file version you care about.

For high-value files, verify at least:

1. remote existence — can you see the file in the provider's web interface?
2. remote recency — does the modified time/content correspond to your latest edit?
3. remote size — is the size plausible?
4. remote open/download test — can a fresh browser session or second device retrieve it?
5. checksum when warranted — for large archives or irreplaceable binaries, compare the downloaded copy against the source.

If those checks fail, stop treating the local file as cache.

It is a recovery source.

For a deeper integrity workflow after upload, the site's existing cache explainer is not enough; the underlying principle is the same one used in any serious backup design: the copy is only trustworthy after you can restore and verify it. Cloud Backup vs Cloud Storage explains why synchronization state and independent recovery are different jobs.

Do not confuse “clear cache” with “remove local copy”

These operations can look similar because both free disk space, but they are semantically different.

Supported dehydration / online-only transition

Examples include:

• OneDrive Free up space;
• Dropbox online-only;
• iCloud Remove Download.

The provider understands the operation and keeps the cloud object authoritative.

Manual cache deletion

You remove files from a hidden or internal client-managed location.

The provider may or may not have documented that exact action. The client may have pending transfer state there. The file may be replaceable — or it may contain the only latest edit.

Reset / rebuild

A supported reset intentionally discards or rebuilds some client state while preserving server data and, in better implementations, accounting for unsynced local changes.

These are not interchangeable maintenance verbs.

The safest troubleshooting order

When a cloud client is stuck, use this sequence instead of jumping directly to cache deletion.

1. Stop creating new changes

Do not keep editing, renaming and moving files while the sync engine is already failing. Every new change increases the reconciliation surface.

2. Identify the latest local-only work

Sort by recently modified files. Look for provider status such as:

• pending;
• waiting to upload;
• sync error;
• conflict;
• locally available but not confirmed remotely.

3. Verify the server copy

Use the provider's web interface or a second device. Check the actual newest content, not just the filename.

4. Copy uncertain files outside the managed sync tree

This is the safety checkpoint.

Create a temporary recovery folder on a normal local disk or another independent destination and copy the uncertain files there. Do not move them; keep the original topology intact until the repair is finished.

5. Prefer provider-supported space controls

If the problem is disk space:

• online-only;
• Free up space;
• Remove Download;
• selective sync;
• pCloud Disk Usage.

Use the product's own state transition before deleting hidden files.

6. Prefer provider-supported reset / repair

If the problem is corrupt sync state, use the vendor's documented repair or reconnect sequence.

7. Only clear a documented cache when its prerequisites are satisfied

For Dropbox, for example, fully stop the client first. For Google Drive Stream, do not clear cache while unverified local edits may still exist there.

8. Reconnect and let the client settle

Do not immediately begin a mass rename or move while the client is rebuilding its state.

9. Compare preserved local copies with the rebuilt cloud state

Only after you know which version is authoritative should you delete temporary recovery copies.

What not to do when a client says “sync pending”

Several popular troubleshooting habits are disproportionately risky:

• deleting every hidden folder whose name contains cache;
• signing out of the account before checking pending uploads;
• uninstalling and manually deleting all residual application data at once;
• moving the entire sync root while sync is already unhealthy;
• using “Free up space” logic on a file whose latest edit has not uploaded;
• assuming a placeholder visible in Finder/File Explorer proves the newest bytes exist remotely;
• emptying Trash/Recycle Bin before understanding whether an unsynced file was moved there;
• using a third-party cleaner that does not understand the sync client's state database.

The common failure is the same: the repair removes evidence before you know which copy is authoritative.

When cache clearing is actually reasonable

Cache clearing is reasonable when all of these are true:

• the provider documents the cache or reset action;
• the client is fully stopped if required;
• recent important changes are confirmed remotely;
• any uncertain local-only work has been copied outside the sync tree;
• the action does not delete the actual mirrored source folder;
• you understand that the next launch may trigger a full rescan or re-download;
• you have enough disk and network capacity for that rebuild.

That is a very different condition from “sync is slow, so delete cache.”

The archive-design lesson behind the troubleshooting problem

Many people only discover this issue because one cloud client is being asked to do too many roles at once:

• hold a multi-terabyte archive;
• keep everything locally mirrored;
• provide offline access;
• act as the only backup;
• preserve unsynced working edits;
• recover deleted files;
• save local disk space at the same time.

Those requirements conflict.

A cleaner design separates:

• active working folders that genuinely need two-way sync and offline access;
• cloud-first archive data that does not need a permanent full local mirror;
• independent backup/recovery copies that are not merely another view of the same sync state.

If your cloud client repeatedly needs emergency cache surgery just to keep the workflow alive, the unresolved problem may no longer be the cache. It may be the storage architecture.

Evidence boundaries and what we are not claiming

To keep this article technically honest:

• We are claiming that Google documents loss risk for unsynced Stream-mode changes when its cache is cleared or corrupted.
• We are claiming that Microsoft documents OneDrive Reset as a supported operation that does not delete OneDrive data.
• We are claiming that Dropbox documents a manual cache-clearing procedure and identifies the cache as an upload/download staging area.
• We are claiming that Apple marks Waiting to Upload items as not yet stored in iCloud and provides supported Remove Download behavior.
• We are claiming that pCloud documents cache-size controls and alternative upload behavior.
• We are not claiming that every vendor's undocumented internal cache directories are safe to delete.
• We are not claiming that a successful reset proves every prior local edit reached the cloud.
• We are not claiming that cache clearing is a substitute for backup.

Sources checked on 21 August 2026

Primary vendor sources:

1. Google Drive Help — Manage Google Drive for desktop: Advanced guide

https://support.google.com/drive/answer/16631477

1. Google Drive Help — Customize Drive for desktop settings

https://support.google.com/drive/answer/13470231

1. Microsoft Support — Reset OneDrive

https://support.microsoft.com/en-US/onedrive/reset-onedrive

1. Microsoft Support — Repair sync connections in OneDrive for work or school

https://support.microsoft.com/en-us/onedrive/repair-sync-connections-in-onedrive-for-work-or-school

1. Microsoft Support — Save disk space with OneDrive Files On-Demand for Windows

https://support.microsoft.com/en-us/onedrive/save-disk-space-with-onedrive-files-on-demand-for-windows

1. Dropbox Help — How to clear the Dropbox cache folder

https://help.dropbox.com/delete-restore/cache-folder

1. Dropbox Help — Fix Dropbox files not syncing

https://help.dropbox.com/sync/files-not-syncing

1. Dropbox Help — How to use Dropbox to save hard drive space

https://help.dropbox.com/sync/make-files-online-only

1. Apple Support — Check your iCloud Drive file and folder status on Mac

https://support.apple.com/en-ca/guide/mac-help/mchlc994344b/mac

1. Apple Support — Work with folders and files in iCloud Drive

https://support.apple.com/en-ie/guide/mac-help/mchl1a02d711/mac

1. pCloud Help — Low disk space warning in pCloud Drive

https://help.pcloud.com/article/low-disk-space-warning-in-pcloud-drive

1. pCloud Help — pCloud Drive vs (pCloud) Sync

https://help.pcloud.com/article/pcloud-drive-vs-pcloud-sync