If you have ever run a PowerShell script to move or rename a folder on Google Drive for Desktop and hit a vague permission error, you are not alone. The folder is right there. Nothing in Task Manager shows it as open. Yet Windows refuses to move it. The error says "access denied" or "file in use" with no further explanation. This is a known quirk of how Google Drive holds file handles during an active sync.

Why Drive Locks Folders During Sync

Google Drive for Desktop does not just copy files to your machine. It holds open handles on folders and their contents while it syncs changes to the cloud. From Windows' perspective, those handles count as active locks. Any script that tries to move, rename, or delete the folder while Drive is mid-sync will fail. The process holding the lock does not always show up cleanly in Task Manager because Drive manages it internally. You are not doing anything wrong. Drive is just in the middle of something.

The fix is not to force the move. The fix is to pause Drive first, let it confirm the pause, run your operation, then resume. One extra minute saves a frustrating debugging loop.

The Reliable Fix: Pause, Move, Resume

Before running any script that touches folders inside your Drive path, pause sync from the Drive for Desktop system tray icon. Click the icon, open the menu, and select "Pause syncing." Wait for the icon to show that sync is fully paused, not just pausing. Then run your move or rename operation. After the script finishes, verify the result with Test-Path to confirm the folder landed where you expected. Once confirmed, resume syncing. Drive will catch up on its own.

When pausing is not an option, for example in an automated routine that runs without user interaction, do not attempt a move at all. Rename the folder with a _DEPRECATED suffix instead. This sidesteps the lock entirely because renaming in place does not trigger the same handle conflict as moving across directories. Your script stays clean, Drive does not complain, and you can do the actual cleanup later during a manual session when you can pause sync properly.

What This Looks Like in Practice

At Balay ni Bruno & Co., this issue came up while building folder management scripts for the BBC Drive. The pattern is now documented and baked into every Drive-touching script: pause first, operate second, verify third, resume last. If the script is unattended, fall back to the rename workaround. It is a small discipline that saves a big headache. Windows, PowerShell, and Google Drive can all work together cleanly once you respect the sync lock.

Key Takeaways

  • Pause Drive Desktop sync before any folder rename or move in a shared drive.
  • Drive file handles during sync show up as permission errors, not sync errors.
  • The _DEPRECATED rename-in-place workaround avoids the lock entirely.
  • Test-Path after every move catches silent failures before they cascade.