1

I'm developing a change tracking software to monitor files of a specific volume. I tried FileSystemWatcher (.NET) and AlternateDataStreams but they all have some limitations (ie. the change tracking software has to be on 24/7, alternate data streams to not work for ReadOnly files, etc.).

After some investigations I thought that I could directly read the NTFS change journal. This works great if the file is moved/renamed, etc. on the same volume. For identifying the file I'm using the File Reference Number.

But if the file is moved to another volume, the File Reference Number naturally changes.

My question: Is there a unique ID (GUID or something else) that doesn't change even if the file is moved to another volume?

pego
  • 117
  • 1
  • 9

1 Answers1

2

Well...there can be a file GUID, but it's not there by default.

If you have the necessary permissions, you can race through the files and assign a GUID which will be preserved across NTFS volume moves. Your stated goal is exactly why the feature exists. It uses a somewhat unwieldy API called DeviceIOControl...which is used for a gazillion purposes...but one of it's control codes is FSCTL_CREATE_OR_GET_OBJECT_ID. Check here for details.

It only creates the GUID if one hasn't already been assigned...which is just how you want it to work. Of course, if the file moves to a non-NTFS volume, you're still outta luck.

Clay
  • 4,999
  • 1
  • 28
  • 45
  • ah sounds promising - I'll give it a try and let you know if that helped – pego Sep 03 '18 at 08:25
  • @pego, get anywhere? – Clay Sep 10 '18 at 20:10
  • AWESOME - I checked out FSCTL_CREATE_OR_GET_OBJECT_ID today and it works like a charm. The Object_ID is persisted even if the file or directory is moved to another volume. FSCTL_CREATE_OR_GET_OBJECT_ID works also for ReadOnly Files/Directories. Thanks for your support! – pego Sep 13 '18 at 13:48