Column to display (1 or more) FileId values assigned to an NTFS Entity and Column for HardLink Count

Is there already, or is there an approach, or is there a feature possibility to support a column that displays:

  • Files HardLink count
  • File or Dirs Stream Count
  • File or Dirs NTFS/ReFs/SMB FileId (Guid if one is assigned, and intrinsic 64-bit $MFT FileIndex Id/inode)

Scripts can add new columns, so if the information is accessible from JScript or VBScript in some way, that would be one way to do it (assuming there aren't existing shell extensions to provide such columns).

Thank you Leo!

I was thinking it might be (slow down listers) expensive to apply a script to every File and Folder for that info. But you're right it could be done by scripts or an extension.

I am sure that internally DOpus knows the stream-count and/or FileId since they are returned by the OS/NTFS as part of the Dir record enumeration. Probably done by GetFileInformationByHandleEx class FileIdExtdDirectoryInfo, etc.

Speed shouldn't be too bad. Script columns are populated via a background thread so it won't hold up the initial folder display or anything like that.

You could have a button/hotkey/etc. to toggle it on only when you need the extra info, or configure folder formats so it was only shown in/below certain folders to avoid the extra work everywhere else.

The main problem may be getting the data from a script, as I'm not sure if it is exposed to scripts or not (via the Windows scripting objects; I know for sure it isn't currently exposed by the Opus scripting objects). Maybe it is, though; it's not something I've needed in scripting before so I may just not have seen it.

On the Opus side, exposing Windows APIs to scripts is usually fairly easy, so we can add that if it would be useful. Maybe there are other things you'd like to do with the same information in scripts? But it's equally easy to add new columns if the only thing you'd want the info for is to display it. (Although columns had the extra overhead of requiring new string resources that get translated, so adding scripting APIs is a bit quicker/easier.)

Opus does already get some of that information itself, but I think only in special places and it doesn't get/store any of it for in-memory records of each file in the file display. It can be added, but isn't already there just needing the plumbing to expose it; it'd need a bit more than than.