Hi DW.

I would like to know if its possible to get the source path of a file copied/moved to a folder I set a FileSystemWatcher? What I mean is that get the location as to where this file is coming from if its was copied/moved into this folder.

Thank you.

Dani AI

Generated

Short answer for anyone landing here later: FileSystemWatcher alone will not tell you the original location a file was copied from. ’s point is correct — the managed watcher only sees the file arrive. To actually know “where it came from” you need either the source to record that information, or a lower/higher‑level monitoring strategy that captures the operation as it happens.

Practical options (tradeoffs in a nutshell):

  • If you control the copier: write the origin into the file’s metadata (for example an NTFS alternate data stream or a small sidecar file). This is the simplest and most portable approach when you control both sides, but ADS won’t survive copies to non‑NTFS targets.
  • If you don’t control the copier and you need full coverage: intercept at the OS level. A kernel minifilter can observe create/open operations and the creating process, giving the best chance to identify origin — but it requires WDK work, driver signing, careful testing and maintenance. (This echoes ’s suggestion but with the deployment caveats.)
  • A middle ground: use the NTFS change (USN) journal or file IDs to correlate events on the same volume. That can let you reconstruct moves/renames inside a volume without a kernel hook, but it won’t help for cross‑volume copies or for removable FAT media. ’s USB concern is important — removable or non‑NTFS volumes limit many of these techniques.

Notes and cautions: kernel filters are powerful but complex and carry system‑stability and signing implications. Metadata approaches are low cost but fragile across filesystems and network copies. Server‑side logging / SMB auditing can help when the source is a network share. Choose based on where the source files live (local NTFS, network share, removable media) and whether you can change the source behavior — if you can, add metadata; if you can’t, plan for a minifilter or USN‑based reconciliation and be prepared for the added complexity.

Recommended Answers

All 7 Replies

The FileSystemWatcher can be triggered on

Created
Deleted
Changed

events. As far as it is concerned, when a files is copied/moved into the watched folder, it is considered as a Created event. There is no way to determine where the file came from.

@MrM, I checked the prior discussion you had on this and read the document linked and agree that this doesn't do that. On top of that it appears not to track USB stick changes/events.

Why not start a thread telling all your app is trying to accomplish? You had a long series of discussions about how to break MP3s and this sounds as if you are still pursing something down dead ends and blind alleys.

Just a file system filter driver would do the job.

commented: Should be interesting to see Mr.M's take on this answer. Good find. +12

Ok cool. I will check this out and see, , well I must say I'm actually going forward and also regarding the post you are refering to, I've also mark most of them as solve because I managed to find solutions to it.

This also make me a bit suspecious that you are also following me and my posts. Are you also trying to do what I'm doing? because I'm way to far now. infact I'm almost done with my project.

Hi Mr.M. I checked your prior posts to better understand what the big picture is on your project. Is that unacceptable?

Nah didn't say that. Thought maybe there's another reason behind.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.