Currently the metadata panel standard properties does-not include the standard file-system attribute for marking an item as "indexable".
It would be great to see that [checkbox] added to the Metadata:Standard Properties, and "I" to the "SetAttr ATTR /K" list (etc), and the "Attr" column in the lister. The "L" and "J" flags are what Microsoft uses to display links in its attr-properties so those might be good to add to the "Attr" column at the same (update) time.
Thank you!
David Simmons
In my tools and scripts the "I" FSE attribute indicates whether a SCM (git, etc) or backup-tool should include that entity when looking for things to add/remove to its "include, index, important, ..." monitored list. Thus serving similar purpose to .gitgnore file semantics, but intrinsically usable in ntfs/DOpus to attach on the file or directory itself.
Aside - but related:
Note: the "I" and "A" pattern usage (for SymLink-target archive semantics) discussed below, works equally on all modern OS file systems [OSX (bsd variants), Linux, iOS, etc]; which means it works well with NAS Samba/SMB/CIFS shared drives and mountable HVS disk-image formats like "VHDX, IMG, VMDK (and also DMG)" files.
Window's 10 Anniversary adds Linux-Beta NT-subsystem support that uses NTFS Alternate Data Streams (Forks) to record linux-compatible attributes and xattrs. It might be a good idea if DOpus (rather than just writing a user-defined custom lister column) helped standardize display of those Microsoft defined Alternate Data Stream lxss attributes in the lister as well as display and modification of them in the Metadata panel.
Being able to "edit" the symlink (reparse-point or junction) path-target in the Metadata panel would be "very-useful" for fixing or addressing broken path's. Especially since the "property" panel modally blocks property-tab actions by displaying a modal dialog saying the target is invalid and then not allowing any changes to be made.
Note: removing (/D or /J links) reparse-point xattr data from a directory does not not require Elevated Admin (UAC) permissions, but writing it does. Junction (/J) reparse-points xattr data added to a directory turns the directory into a "mount point referencing a \?... NT Object Path". SymLinks (/D) reparse-points xattr data added to a directory turns the directory into a FSE (file system entity) path redirect.
SymLink-Directories and Junctions are actually ordinary directories with ntfs reparse-point xattr data added. So if you remove the reparse-point data you have an ordinary directory again. (see below, the same is true for SymLink-Files).
Technical note: when, from code, one accesses a directory or file (the link-container-itself) with a reparse-xattr, you can tell the operating system to open it "ignoring" the reparse-xattr allowing your code to read and/or write the content within the directory or file (link-container-itself).
The significance of this is that it means there is always an underlying directory. So, when applying attribute and metadata actions it is important to have control and visibility regarding when they apply to the target of the link, versus the link-itself (i.e., the reparse-point-directory itself containing the xattr link-reparse-target data). You can see this in many Microsoft command-line tools expressed through the "/L" switch (such as attrib).
A file (as opposed to a directory) that is a SymLink works exactly the same way as a "/D" directory. It is an ordinary file whose content-fork is ignored when it has a ntfs-reparse-point xattr attached. Given that a SymLink-File has an underlying NTFS FSE file (just as SymLink-Directories have an underlying directory), ":" alternate-data-stream forks can be associated with them. Doing so allows the link-itself to have its own metadata/ADS-Forks independent of what the link-target may have. I.e., a SymLink and its Target are two independent real NTFS FSE objects with all the corresponding capabilities for forks (including the DOpus fork metadata, tags), etc.
In my tools and scripts use the "I" FSE attributes to indicate whether a SCM (git, etc) or backup-tool should include that entity when looking for things to add/remove to its "include, index, important, ..." monitored list.
I use the "A" (archive) attribute on a SymLink-itself, with on (ntfs default) indicating that a copy or move (archiving action [data preserving semantic]) should be applied to the link-target, and off indicating that it should be applied to the link-itself.
Noting that NTFS always sets "A" when a file (or directory itself - not its contents) is touched, this works almost perfectly for SymLinks since it is a "opt-in" model to turn off the "A" to indicate I want the copy or move to work with SymLink and not its target.
The "A" is irrelevant for deletion since it is never desirable to have a gui/shell/explorer/cli action (default to) delete the target of a SymLink (that must always be an explicitly ask or action [data destruction semantic]). I.e., you want the default to only delete the link-and-its-container, not the link-target.
Specifically, this becomes very crucial for dealing with archiving such as zips or working with source-code control repositories (scm's) like git where (like on OSX and Linux) one wants to be able to control whether a SymLink itself or its target-contents will be archived and acted upon. i.e., to say "please back up this SymLink as itself, rather than backing up what it's target refers to".
For this reason I have worked to configure custom-columns (and ideally DOpus auto-labeling with color) on any SymLinks that have the "A" cleared versus set so that I can visually see when a SymLink is only for FSE (explorer/cli) navigation, versus being used as an explicit copy/move alias for its target.
Being able to "see" (forks) alternate data streams associated with a given file or folder in the Metadata panel would be "very-useful" as well. Ideally in a mini-lister style showing name, dates, attrs, etc.
And, I guess it is worthy of discussion to add bundling VHD/VHDX operations (and auto-mount TaskScheduler) item together with the above, since they actually form part-and-parcel of a file-management pattern. I uniformly on all our machines and servers use a vhdx [and 7z tools with wim files] and symlinks to portably abstract and support system installations and have it automounted with network share subdirectories using the task-scheduler at startup. It integrates devops work very cleanly in a NAS (network addressable storage) [samba/smb/cifs] environment of bare-metal and virtual machines and docker or Microsoft containers and iot devices.
Specifically, for general devops work that includes features above, it would be useful as a default DOpus feature (I have custom code), to support VHD/VHDX [create, mount, unmount, resize, shadow-copy backup] operations directly from a lister (as well as SymLink, SCM, Dokan/Fuse, and SqLite integration).