Why Do Multi-File Copies From Explorer Lose Files?

Select twelve files in File Explorer, Ctrl+C, paste in another folder, and all twelve arrive. The same copy, watched by a clipboard manager or an Electron app, sometimes shows one file. That is a classic read bug, not Explorer dropping names. Microsoft Learn is explicit: CF_HDROP is a group of existing files. CFSTR_FILENAME is a single fully qualified path, kept for old apps and superseded by HDROP.

This page is the first-path problem: how a complete HDROP read works, why “FileNameW” shortcuts miss files, and how to tell a tool bug from a destination that only accepts one attachment.

What Explorer actually published

Microsoft Learn, CF_HDROP:

• Predefined format; no RegisterClipboardFormat required.
• DROPFILES plus a double-null-terminated array of fully qualified paths.
• Example shape: c:\temp1.txt\0c:\temp2.txt\0\0
• DragQueryFile extracts names.

Microsoft Learn, handling Shell data transfers:

1. Get CF_HDROP as an HGLOBAL.
2. Call DragQueryFile with iFile = 0xFFFFFFFF to get the count.
3. Call DragQueryFile once per index to get each path.

If a tool does that, it sees every selected file. Explorer paste does that. How Windows File Drop Lists Actually Work. How to Copy Multiple Files and Paste Them Somewhere Else.

The single-name format

Microsoft Learn, CFSTR_FILENAME:

• Transfers a single file.
• A null-terminated fully qualified path.
• Superseded by CF_HDROP.
• Supported for backward compatibility with Windows 3.1 applications.

On many systems the registered Unicode name appears as FileNameW (and ANSI as FileName). Those names are the compatibility formats. They are not the full list. A manager that only calls “get FileNameW” will store the first path and ignore the rest. That matches the ticket “the clipboard only copied one file.”

This article will not invent additional undocumented OLE interfaces. The documented pair is: read CF_HDROP + DragQueryFile for a group; treat CFSTR_FILENAME as one path.

Some .NET helpers wrap this correctly (Clipboard.GetFileDropList in Windows Forms is documented as a collection of path strings). Wrappers that expose a single GetFileName() do not.

Other reasons only one file shows up

Not every miss is FileNameW.

Win+V is never the debugger for multi-file copy. History is text, HTML, bitmap, 25 items, 4 MB, restart wipe except pins.

Virtual objects and incomplete lists

Not every Explorer selection is a simple file-system group. Search results, libraries, and some namespace folders may also offer CFSTR_SHELLIDLIST (PIDLs). Microsoft Learn: existing file-system files should still be offered with CF_HDROP. If HDROP is missing, the source is not a plain folder of files. Copy from the real folder path.

ZIP preview can produce temp paths for only the items Explorer extracted. Copying From a ZIP Preview vs Extracting First.

How to test a tool in five minutes

1. Create a folder with three tiny text files a.txt, b.txt, c.txt.
2. Select all three in Explorer. Ctrl+C.
3. Paste into a second folder. Confirm three files. Explorer is the control.
4. Inspect the tool. If it shows one card named a.txt and nothing else, it did not walk HDROP.
5. Drag out of the tool into a third folder. If only a.txt appears, its drag-out also published a single-name format.

A well-behaved drag-out rebuilds CF_HDROP with every remaining path. Publishing only CFSTR_FILENAME repeats the bug in the other direction.

Dragging Several Files as One Stack.

Electron and “HTML5 file drag”

Webviews can see a FileList from an <input> or an internal drag. That list is not automatically the Windows clipboard HDROP. Unless the app bridges to a native data object, Explorer will not receive twelve files. This is a product architecture issue. Do not assume a JavaScript DataTransfer.files.length of 12 means the OLE object Explorer sees has 12 names.

When the exact bridge API of a given framework is uncertain, use the Explorer paste test above. The desktop result is the spec.

CFSTR_FILECONTENTS is a different kind of “many files”

Microsoft Learn documents CFSTR_FILEDESCRIPTOR + CFSTR_FILECONTENTS for data that should look like files but is not already on disk (email attachments in a database, for example). Each file has a descriptor and a stream. That pair is how a source offers virtual files.

A clipboard manager that only understands HDROP will miss those members. A manager that only understands FileNameW will miss both the rest of an HDROP and any virtual files.

Explorer copy of ordinary documents is HDROP, not FILECONTENTS. If a tool claims “we support Outlook attachment drags” it must implement the descriptor/contents pair as Microsoft documented. This article will not invent extra OLE methods for that pair.

Users can avoid the whole class by saving attachments to a folder first, then copying in Explorer. The paths become real, HDROP works, and incomplete readers have a better chance — still walk the full list.

What users should do while the tool is wrong

• Paste with Explorer, not the manager, for multi-file copies.
• Zip the set and copy the zip (one path, complete contents).
• Use a staging folder.
• Do not enable more Windows history settings; they cannot see HDROP.

A local shelf that documents native HDROP drag-out — Edge-Drop aims at that job — is optional once the tool has been tested with three files. If a manager still stores one name, pick a different manager for file packs. Ditto-style text history can be excellent and still be weak at files.

FAQ

Does Windows only put one file on the clipboard? No. Explorer publishes the whole selection as one HDROP. Paste in a second folder is the proof.

Why does Win+V show none of them? History is text, HTML, and bitmap. Files are not listed. That is separate from the one-file bug.

Is FileNameW a bug in Windows? No. Microsoft documents CFSTR_FILENAME as a single path for old apps. The bug is using it as the only reader.

Can the user fix FileNameW in Settings? No. There is no consumer toggle. Use Explorer paste or a tool that walks HDROP.

What about selecting files from two folders? Explorer copy is per-window selection. Stage into one folder first, then copy.

Selecting files from Quick access without opening the real folder can also produce a short list. Microsoft Support says to Open Quick access items before cut and paste. Open the folder, select, copy.

Related reading

• Dragging Out of a Clipboard App Into an Elevated Window
• Internal Drag vs External Drag in Clipboard UIs
• Why You Cannot Drag Old Clipboard Files Into Explorer
• How to Get a Screenshot Into Photoshop Without Recopying

Sources

• Shell Clipboard Formats (Microsoft Learn) — CF_HDROP group of paths; CFSTR_FILENAME single path superseded by HDROP.
• Handling Shell Data Transfer Scenarios (Microsoft Learn) — DragQueryFile count with 0xFFFFFFFF, then each index; existing files should offer HDROP.
• Standard Clipboard Formats (Microsoft Learn) — CF_HDROP definition.
• Clipboard.GetFileDropList (Microsoft Learn) — file drop list as a collection of path strings.
• Using the clipboard (Microsoft Support) — Win+V will not list the files at all.

Copy. Stack. Drop.

Transform your clipboard into an interactive edge shelf. Stack, pin, and drag assets into any app with zero friction.

Download for Windows Get from Microsoft Store

How to Install Guide · First 10 Minutes Guide · Drag & Drop Guide · Edge-Drop vs Win+V · Support