Copy an entire folder in Google Drive, contents included
How to check a folder copy actually finished: taking an inventory first, reconciling counts afterwards, and repairing the categories of file that tend to go missing.
Rithul Palazhi10 min read
On this page
The difficult word is "entire". Running a folder copy is straightforward, and four methods do it reliably. Knowing that everything arrived is a separate problem, because Drive copies fail partially and quietly: no error, no summary, just a folder that looks approximately right and is missing eleven files somewhere four levels down.
This page is about closing that gap. Take an inventory before you start, reconcile afterwards, and know which categories of file need handling separately so you can check those deliberately rather than discovering the shortfall in three months.
What we'll cover
Why partial copies are hard to notice
A folder in the Drive interface shows you one level at a time. Open the copy, see the subfolders you expected, and it looks finished. The files that did not make it are three levels below the screen you are looking at, and nothing aggregates that view for you.
The methods each fail differently, which is worth knowing so you check the right thing.
A browser copy silently omits every subfolder. The top level looks fine and the structure below it was never attempted.
A desktop client copy can stop when your machine runs out of disk space, loses its connection, or goes to sleep. It generally resumes, though a copy interrupted mid-upload can leave zero-byte files that look present in a listing.
An Apps Script copy stops when it hits the execution time limit. Because the script recurses depth-first, what you get is a tree that is complete down one branch and entirely absent down another, which is the most confusing failure of the three.
In all three, the operation reports nothing. There is no completion summary, no count, no list of skipped items.
Take an inventory before you copy
Two minutes here saves a great deal of doubt afterwards. This script walks a folder and reports totals by depth, so you have a number to compare against.
function inventory(folderId) {
const counts = { files: 0, folders: 0, bytes: 0, byDepth: {} };
function walk(folder, depth) {
counts.byDepth[depth] = counts.byDepth[depth] || { files: 0, folders: 0 };
const files = folder.getFiles();
while (files.hasNext()) {
const file = files.next();
counts.files += 1;
counts.byDepth[depth].files += 1;
try {
counts.bytes += file.getSize();
} catch (e) {
// Google-format files report no size; skip them.
}
}
const folders = folder.getFolders();
while (folders.hasNext()) {
counts.folders += 1;
counts.byDepth[depth].folders += 1;
walk(folders.next(), depth + 1);
}
}
walk(DriveApp.getFolderById(folderId), 0);
Logger.log(JSON.stringify(counts, null, 2));
return counts;
}
Run it on the source folder and keep the output. Run it on the copy when the operation finishes. If the two sets of numbers match at every depth, you are done. Where they differ, the depth breakdown tells you which level to go looking at, which is far quicker than opening folders one by one.
The byte total is worth noting separately: it counts only files that report a size, so Google Docs and Sheets are excluded. A copy that matches on file count but differs substantially on bytes usually means files uploaded as empty.
Reconcile the two sides afterwards
Where the counts differ, the gap falls into one of a small number of categories, and identifying which one tells you what to do next.
Subfolders missing entirely at depth 1. A browser copy was used on a nested folder. Redo it with the desktop client or a script.
One branch complete, another absent. An Apps Script run hit its time limit. Delete the partial copy before retrying, since resuming onto it creates duplicates of what already succeeded.
A handful of files missing, scattered across depths. Individual files that could not be copied, almost always because of permissions. These need identifying by name, which the next section covers.
Counts match but sizes differ. Interrupted uploads. Sort the copy by size in the Drive interface and look for zero-byte entries.
To list the specific files that failed rather than just counting them, adapt the inventory script to collect file names into an array at each depth, run it on both sides, and compare the two lists. For a folder of any size this is considerably more useful than counts alone, because it hands you the exact names to investigate.
Checking without writing any code
Not everyone wants to run a script, and for moderate folders the Drive interface gives you enough to check properly.
Use search scoped to the folder. Open the folder and search within it. A query of * inside a parent returns everything beneath it including subfolder contents, which is the flat view the folder listing refuses to give you. Do this on both source and copy and compare the result counts shown.
Sort by size to find empty files. Switch the copy to list view and sort by size. Zero-byte entries are interrupted uploads, and they cluster together at one end where they are easy to spot.
Sort by modified date on the copy. Every file in a successful copy was created within the same window. Anything with an older timestamp was not created by this operation, which usually means you are looking at a previous partial attempt rather than the copy you just made.
Spot-check the deepest branch. Find the most deeply nested folder in the source, then navigate to the same path in the copy. Depth-first failures show up at the far end of the tree, so if the deepest branch is intact the run probably completed.
Compare the top level by eye, then one level down. Most failures are visible within two levels: missing subfolders appear immediately, and a browser copy that flattened everything is obvious the moment you look.
This is less rigorous than counting programmatically and it catches the large majority of real problems in about two minutes. Use the script when the folder is large, when the content is important, or when you need a record that the check was done.
The categories that need separate handling
Five kinds of content do not behave like ordinary files during a copy, and each needs a deliberate decision rather than a retry.
Files where the owner disabled copying. When a file is shared with download, print, and copy disabled, that restriction holds against every method, since they all act with your permissions. Nothing you do client-side changes it. The options are to ask the owner for a copy, ask them to lift the restriction, or accept the gap and record it.
Shortcuts. These copy as shortcuts, still pointing at the original targets. The copy is structurally complete and functionally hollow, because none of the referenced content was duplicated. If the shortcuts pointed at things you also wanted copies of, they need handling as their own pass: resolve each shortcut to its target, copy the target, then create a shortcut to the new copy.
Google Forms. A copied form loses its connection to the original response destination. Reconnect it on the new form, or it will collect responses into nothing.
Files owned outside your organization. Domain sharing policies frequently block copying content across an organizational boundary, which appears as a permission error on those specific files while everything else succeeds.
Very large Google-format files. Sheets near the cell limit and Docs with heavy embedded content can fail conversion during a copy. These are rare and obvious once you know to look, because they are usually the files everyone already knows are too big.
Deep trees and execution limits
A script that recurses depth-first through a large tree will exhaust its execution allowance before finishing: six minutes on consumer accounts, thirty on Workspace. What makes this worse than a plain timeout is the shape of the result, with some branches complete and others untouched.
Two approaches get past it.
Copy in stages by hand. Run the copy separately on each top-level subfolder, so each run is small enough to finish. Tedious, effective, and perfectly reasonable for a one-off.
Make the copy resumable. Keep a record of which folders have been processed, write it somewhere persistent such as a sheet or script properties, and have each run pick up where the last stopped. This works and it turns a fifteen-line script into a meaningfully more complex piece of software with state to maintain.
The third option is to stop treating it as a script. An automation platform handles the execution window, the retry behaviour, and the reporting as part of the infrastructure rather than as something you implement. If the copy is large enough to hit these limits, it is usually also important enough that silent partial failure is unacceptable, and that combination is the argument for building it properly.
Making completeness routine
Where a folder copy happens repeatedly, verification should not be a thing someone remembers to do. Build the check into the process: count the source, run the copy, count the result, and report the comparison. A copy that reports "412 files, 38 folders, matched" is trustworthy in a way that a copy reporting nothing never is.
This is straightforward to describe and tedious to write by hand, which makes it a good candidate for automating. On CodeWords you describe the whole thing in plain language, including the part that matters most: what should happen when the counts do not match. Cody, the automation builder, builds it, connects it to Drive and to wherever you want the report sent, and deploys it. Automations connect to more than 3,000 integrations. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.
The part worth specifying carefully is the failure path. A copy that stops and tells you is recoverable. A copy that continues and says nothing is how eleven files go missing for three months.
Frequently asked questions
How do I know the copy finished if there is no progress indicator?
Compare counts on both sides, which is the only reliable signal Drive gives you. The inventory script above produces the numbers. Doing it by eye works only for folders small enough to see at once, which are also the folders least likely to have a problem.
Why do some files copy and others in the same folder do not?
Almost always permissions, applied per file rather than per folder. A folder can hold your own documents alongside files shared with you by three different people under three different policies, and a copy succeeds or fails on each independently.
Does copying preserve the folder structure exactly?
With the desktop client, a script, or an automation, yes, including nesting at any depth. Copying by selecting files in the browser does not, because subfolders are not included in the selection.
What happens to files I have shortcuts to?
The shortcut is duplicated and continues pointing at the original target. Nothing the shortcut refers to is copied. If you need the referenced content duplicated too, that is a separate pass over the shortcuts specifically.
Can I copy a folder that is larger than my remaining storage?
No, and the failure arrives partway through rather than at the start. Check the source size against your available quota before beginning, remembering that copies made in My Drive count against the copier's allowance regardless of who owned the originals.
Is there a way to copy only files changed since last time?
Not with a plain copy, which has no memory of previous runs. An automation can hold that state, comparing modification timestamps and copying only what changed, which is the sensible pattern for keeping a duplicate roughly current without repeating the whole operation.