# USBCopyer: automatic file copying from USB drives on Windows

> A GPL-3.0 C# tray application that copies files off a USB drive the moment it is plugged in, with filters, delay, size limits and Git version control. It is a Windows-only tool with a narrow, explicit purpose.

**kenvix/USBCopyer** — 😉 用于在插上U盘后自动按需复制该U盘的文件。”备份&偷U盘文件的神器”（写作USBCopyer，读作USBCopier）

- Repository: https://github.com/kenvix/USBCopyer
- Website: https://kenvix.com/post/usbcopyer/
- Stars: 3,000 · Forks: 493
- Language: C#
- License: GPL-3.0
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/kenvix-usbcopyer

## What USBCopyer is for, and who actually needs it

The README states the purpose directly: the program copies files from a target USB drive after it is plugged in, on demand. The repository describes it as a tool for backing up and copying USB drive contents. The listed scenarios are narrow and concrete: collecting a lecturer's courseware, pulling data off a drive inserted into a public computer, backing up a USB drive quickly, and backing that backup with version control. This is not a sync client and not a general file manager. It watches for removable storage and copies out of it.

The audience follows from that. Someone running a lab, a classroom PC, a print shop counter or a shared workstation has a recurring problem: drives arrive, files need to leave with them, and nobody is sitting there to drag folders. USBCopyer handles that case on Windows only. The README offers a .NET Framework 4.0 build for Windows 8 and Windows 10 and a .NET Framework 3.5 build for Windows 7, Vista and XP, which tells you the intended deployment surface is older Windows estates, not modern cross-platform servers.

## How the copying mechanism and its filters work

The program runs in the tray. The README shows two icons: the default icon means idle, and a red icon means a copy is in progress. Settings are reached by right-clicking the tray icon. There is no documented service, no daemon, and no remote API; the whole control surface is the tray menu plus command-line switches.

Selection is where the design gets specific. The README lists extension blacklists and whitelists, and disk blacklists and whitelists, with the disk lists able to match on serial number. A whitelist plus version control is described as a convenient way to back up a USB drive, which is the intended combination: restrict to known drives, then keep history. There is also a file size limit, described as a way to avoid delays caused by copying large files, and a delay option. The delay is the interesting one. The README recommends setting a delay and notes that copying should start when the presenter begins the slide show, which is a candid admission that immediate copying competes with the drive's owner for I/O.

Output is organised by a classification rule. The rule expression uses `"` to delimit literal characters, `@` to escape, and `[` `]` to delimit interpolated elements. The available elements are `serial`, `name`, `letter`, `type` and `fs`. The README states the expression is case sensitive, so `[name]` cannot be written as `[Name]` or `[NAME]`, and that literal parts have the highest priority, meaning anything inside quotes is treated as literal except for escapes. The worked example is a rule of `[letter]"-foo[name]bar-@@-"[name]`, which produces a folder per drive under the output directory. Files land in a directory named USBCopyerData according to the FAQ entry about antivirus monitoring.

## Installing USBCopyer and running a first copy

There is no package manager step. The README points to prebuilt executables in the Release directory of the repository, so installation is downloading one file and double-clicking it. Choose the standard .NET Framework 4.0 build for Windows 8 or 10, or the compatibility .NET Framework 3.5 build for Windows 7, Vista or XP. On XP the README warns that .NET Framework 3.5 may need to be installed manually first.

Download the executable from the repository's Release folder. The README gives both a Git@OSC mirror (recommended for users in mainland China) and a GitHub link for each build.

```bash
USBCopyer.Release.exe
```

After launch, the program sits in the tray. Right-click the icon to open the settings and adjust parameters. The README notes that from V5.0 the standard build runs at low privilege, so no UAC prompt appears, and it supports high DPI scaling.

The command-line switches are the part worth knowing before you deploy it, because one of them is a trap.

```bash
USBCopyer.exe [/hide] [/gui] [/reset]
```

`/hide` starts in hidden mode, and the README states the process can then only be ended through Task Manager. `/gui` forces a normal start unless `/hide` is also given, and can be used to escape hidden mode. `/reset` restores default settings and exits, returning exit code 1 on failure; it also escapes hidden mode but discards all settings. The README gives the manual escape hatch for a hidden instance as Win+R followed by `taskkill /f /im USBCopyer.exe`.

For a first real use, plug in the target drive and set the output directory and classification rule in the settings. If you want a drive-specific folder, the rule syntax above is what you edit. Confirm the tray icon turns red during the copy and returns to the default icon when it finishes; that icon state is the only progress indicator the README documents.

## The hidden mode and the restore problem

Two design choices deserve a hard look. The first is hidden mode. A program that deliberately removes its own tray icon and can only be stopped via Task Manager is a program you should deploy with a plan for stopping it. The README provides `/gui` and `/reset` as recovery paths, and `/reset` costs you every setting. This is a legitimate feature for an unattended capture tool, and it is also the kind of feature that gets a tool classified as unwanted software by endpoint protection.

The second is the FAQ entry about target computers with a restore mechanism, meaning machines that reset their disk on reboot. The README's answer is to blacklist your own drive and point the output directory at it, or to kill the restore program with something like PCHunter. The first option is sound but inverts the tool's purpose: you are writing to the drive you plugged in, not reading from it. The second option is an operational decision with consequences well beyond this program. Neither answer is comfortable, and the README does not pretend otherwise.

A related limitation is stated plainly: MTP and PTP devices cannot be copied, with a note that V6.0 might address it. Phones mounted in mass storage mode work. Phones that present as MTP do not, and most modern phones do.

## Callbacks and Git version control

The feature that separates USBCopyer from a simple folder-copy script is the callback. The README says callbacks let you write code to implement behaviour the program does not provide, and that Git version control support is the default example shipped with it. The details of both live outside the README, at kenvix.com/post/usbcopyer-callback/, so this is the point where the repository documentation stops and you have to follow the link.

That is a real gap for evaluation. You can read the README and understand filtering, delays, size limits and folder rules. You cannot read the README and understand the callback interface, what language it expects, how it is registered, or what the Git integration actually commits and when. If Git-backed versioning is the reason you are considering USBCopyer, budget time for that page before committing to the tool.

The FAQ also answers a question that matters once callbacks and Git are in play: how to avoid copying malware. The answer is to install antivirus software and monitor the USBCopyerData directory. That is a reasonable answer and also an admission that the program does not scan what it copies. If you enable version control on a directory that receives files from unknown drives, you are versioning whatever arrives.

## USBCopyer versus a scheduled robocopy or a sync daemon

The obvious alternative on Windows is a scheduled task running robocopy or a similar copy command against the drive letter, or a continuous sync tool such as Syncthing or FreeFileSync pointed at the removable volume. The difference is in the trigger and the policy model.

A scheduled robocopy job copies on a timer, not on insertion, and it has no concept of drive serial numbers, extension filters or per-drive folder rules unless you write that logic yourself in a script. It also does not distinguish between a drive you care about and one you do not. USBCopyer's whitelist-by-serial is the feature that matters here: it lets you say "copy from these drives only" without writing matching code, and the classification rule expression builds the destination folder from the same metadata. A sync daemon goes the other direction, keeping two locations equal, which is not what you want when the source drive will be unplugged and taken away.

Where the script wins is transparency and portability. A robocopy script is text you can read, version and audit, and it runs on any Windows machine without a tray process that can hide itself. USBCopyer wins on setup time for the specific case of "copy whatever arrives on an approved drive, sorted by drive, with a delay so the owner is not blocked." Pick based on whether you want a policy engine or a one-line command.

## Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-03-14. The most recent tagged release is V5.11 from 2018-07-12, with earlier tags V3.8 and V3.5 from 2017. That split matters for anyone planning a deployment: the codebase has seen activity more recently than the published binaries, so the downloadable executables in the Release directory may not reflect the current master branch. If you need a fix that landed after 2018, you are building from source with the Visual Studio solution (USBCopyer.sln) rather than downloading a release.

There is no documented migration path between versions in the README, and `/reset` discards settings outright, so treat configuration as something you record yourself if you manage more than one machine. The README does not document rollback.

On licensing: the repository is GPL-3.0, with the LICENSE file at the top level. That is a copyleft licence, and it has implications if you plan to bundle USBCopyer into a product or link it with proprietary code. The README does not discuss licensing at all, and nothing here is legal advice; if distribution is part of your plan, read the GPL-3.0 text in the repository and get proper counsel.

The upgrade cost is low in the ordinary case. There is no server component, no database and no configuration format to migrate beyond the settings the GUI writes. The cost is concentrated in the hidden-mode and restore-mechanism edge cases, and in the callback and Git features whose documentation lives on the author's blog rather than in the repository.

## Conclusion

USBCopyer fits a Windows machine that repeatedly receives removable drives and needs an unattended copy, for example a shared classroom PC or a kiosk. It does not fit MTP or PTP phones, non-Windows hosts, or anyone who cannot accept a tray process that hides itself by design. Before adopting it, confirm the target machine's .NET level (4.0 standard build or 3.5 compatibility build with a manual .NET 3.5 install on XP), decide the output directory and whether a restore mechanism on that machine will wipe it, and read the callback page at kenvix.com/post/usbcopyer-callback/ if you intend to enable Git version control.

## FAQ

### How do I install USBCopyer on Windows?

Download the prebuilt executable from the Release folder in the repository and run it. The README offers a .NET Framework 4.0 standard build for Windows 8 and 10, and a .NET Framework 3.5 compatibility build for Windows 7, Vista and XP, where the framework may need manual installation.

### Can USBCopyer copy files from a phone?

Not if the phone presents as MTP or PTP. The README states MTP and PTP are not supported and suggests V6.0 might add it, but devices mounted in Mass Storage mode can be copied.

### How do I stop USBCopyer once it is running in hidden mode?

Use Task Manager, or press Win+R and run taskkill /f /im USBCopyer.exe as the README instructs. Starting it again with the /gui parameter also escapes hidden mode, and /reset restores defaults but discards all settings.

### How do I set up Git version control in USBCopyer?

The README says Git version control is the default callback provided, and points to kenvix.com/post/usbcopyer-callback/ for the configuration steps. The repository itself does not document the callback interface or the Git setup.

## Sources

- [kenvix/USBCopyer on GitHub](https://github.com/kenvix/USBCopyer)
- [License: GPL-3.0](https://github.com/kenvix/USBCopyer/blob/master/LICENSE)
- [Project website](https://kenvix.com/post/usbcopyer/)
- [README](https://github.com/kenvix/USBCopyer/blob/master/README.md)
- [Releases](https://github.com/kenvix/USBCopyer/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/kenvix-usbcopyer