I'm surprised there has been no reaction to this post yet since hard links seem to provide a valid third-dimensionality in Windows at least for some use cases.
Some more details. Hard links seem to be no subset of symbolic links, as I wrongly stated above, but info about all those links in the web is really chaotic, and I currently don't grasp the difference (if there is any) between traditional .lnk files and "symlinks", symbolic links. As for applications messing around with, ie breaking hardlinks (ie creating independent file copies instead of treating the original file you want to stay unique), even some plain text editors do this, while others work fine, so you must check every application one by one, and even re-check them after any update, since it's perfectly possible that new versions behave differently from the application's traditional behavior - they call this "progress" then... but without telling you about the unwanted side effects... provided the developers themselves will have discovered them, which isn't necessarily the case...
The main file managers, xplorer2, Directory Opus and XYplorer all seem to create hardlinks from within their respective menus; TotalCommander has got some add-in in order to do this; I don't know other file managers which do it, too, currently, but there might be some.
There is a problem inherent to hardlinks: Since they are all just other denomination/aliases for the original (and unique) file, just like (technically, not by what we'd call it) the very first "hardlink" (see also Leo in
https://resource.dop...ight-hardlinks/16493 , see also below re FPV, I didn't know that special feature there), the regular file system list entry of some file is, deleting the very last hardlink of a file deletes the file itself, or in order words, using hardlinks, when you delete some file entry in your file manager or elsewhere, you can never be sure if you aren't deleting the very last entry, ie the file itself, instead of just deleting a reference. (See my post today re vicinity search: Of course, the "Del" key in some hit list should just delete the file reference from the results list, not the file in question: this is so obvious that I even didn't mention that.)
x2 and DO both come with some - unsufficient? - means to try to prevent file deletion (and since I didn't check, other file managers may do similar things here); some list functionality in DO (see
https://www.gpsoft.c...ks_and_Junctions.htm ; not using DO, I cannot say how this would work in practice), and an additional column in x2 which seems to be the best solution to the problem so far: In x2, if you haven't got list view but details view, you get columns with additional info (for example also for comments, in x2!!! (but unfortunately, these seem to be specific to x2 and cannot be read by other tools checking for the generic comment meta data strings)) - so far, so common behavior of most file managers -, and there seem to be one column for "number of file system entries for the current file" indeed.
x2's isn't the ideal solution to the problem yet, though, since if there is some file in the current folder and which has got an entry count of 2 in that column you will visually check before any file/entry(!) deletion, and if then you think you can safely delete the file's occurrence in the current folder, the (before the deletion) second entry in that column may come from some instance of the file which is already in the bin, and if then you press "Del", the file itself is lost.
What I don't understand here (I didn't try for myself, take the above from x2's forum): A deletion of an entry is deemed to decrease the counter; how come then that a counter of 2, for 1 entry in your current folder and 1 entry in the recycle bin, is possible? Leo (link above) says what I said above: technically, hardlinks are identical to the very first entry of any file, so technically, when you delete a hardlink, there is NO difference to deletion of the "original" file entry, so HOW come a deleted hardlink in the bin shows in the entry-count list, when at the same time hardlink deletion would reset the counter? (In the bin, it cannot be the "file itself" but must be an entry, since the count is for entries, not for files: if it was, the count would always be 1.) So these cannot be true at the same time and should be investigated further; I suppose that if the bin problem is true, then the count to zero will not work but immediately after deleting the bin, or if the bin problem doesn't exist as described in the x2 forum, it would be very easy to implement a safe function for ANY file manager, with or without visual indication (as in x2, DO...):
For ANY deletion of an entry, instead of forwarding this directly to the system (Windows), the file manager would need to check for the count, and then deliver a warning dialog if the entry count is just 1 for some file - which, of course, is the case in 99,999... of the cases for people who don't make extensive use of hardlinks, since "count 1" would be identical to any regular file entry.
For pictures, video clips, music files and the like (subsequently: "pics"), a file manager isn't ideal since you would want to "consume" those files, look at them, listen to them, and most file managers aren't that very good at that; x2 is particularly bad at it, while both XY and DO aren't bad at all here, so they could replace a dedicated pic (etc., see above my "definition") viewer indeed, DO probably even better than XY, but it would be preferable to have this functionality within your dedicated and preferred viewer application indeed.
For example, I prefer FSIV (FastStone Image Viewer) for pictures, over XY (I don't have DO), and it's not very probably FSIV will EVER get such an entry counter/alarm function, considering that currently, even NOT ONE file manager comes with such a functionality; as for the creational function, I've said it above, you do NOT need this function in-built within the application you're using, you can easily do it with some macro which can be applied everywhere: In fact, two macros: 1) identify the current item (with full path, in your file manager, in your pic tool, whatever, and store it, in the clipboard (bad) or in some variable (much better)), 2) create the entry/hardlink, within the (then) current folder in your file manager or other browser tool (and which could even be another one than the one used in 1), with the name you want it to have (input box, default = original file name, also stored in-between).
It's also understood that macro 2 would be ready to be triggered multiple times, for the same input of macro 1 (multiple aliases, the max number per file is 1023, ie 1024 incl. the "original" one, so this should suffice for most use cases, ha, ha) - it's the deletion counter which is missing from applications, not so much the in-built creational functionality... well, at the end of the day, you could create the check-the-aliases-numbers-for-each-deletion on your own, too, making your own functionality overriding the in-built deletion functions (ie intercepting the Del key, etc.) - that could become a little bit complicated for mass deletions, of course... Also, what about moves to different drives? Without having tried, I assume that the innocent moving of an entry ("original" or (other) "alias") will break ALL entries of that file on the original drive (?) since the Windows copy/move function (which the application in question will trigger then, in most cases - some file managers have "robust copy" and such, which behave differently and do, more or less, their own stuff) simply doesn't cope (yet) with hardlinks?
Of course, what you would like to get instead - or perhaps it even functions this way already -, is the creation of a copy (but which will then not be synched in any way further on of course) on that other drive, while leaving the original file (and all its possible entries) on drive 1 unharmed - but copy, with an additional message indeed, telling you the move's making a copy instead since the original file's listed within more than one location; on the other hand, the copy command when copying to another drive should work as expected even now: It would simply copy the current entry of your file to the other drive; for example, if your "original" was was a.x, and your current alias of the file (always on drive 1) is b.x, and there's also some other aliases for that same file, c.x, etc., you'll get a copy of b.x (not a.x) onto drive 2, and any hardlinks over there would be aliases for that new b.x which in time could differ quite considerably from the b.x, a.x, etc. on drive 1 of course - so, as said before, hardlinks come with a cost anyway...
BUT as said above, for pics and so on they could represent an ideal solution for some. As DO's Leo says in the link, FPV (Fast Picture Viewer) has even got in-built functionality... well, I suppose that's just for the creational side. Now FPV is for photographers' needs only, ie for pre-selecting valid pics from the ones coming from your camera, and it's reason for being (raison d'être) is the fact that Adobe Lightroom - where most photographers will then import their FPV preselection into, anyway - is as sluggish as it is; I'd prefer the PhaseOne contender instead, since I think, after some really dreadful experiences, that the LR workflow is absolutely terrible anyway, also and especially for photographers, but as always, your mileage may vary; in the end, it all comes down to the old question if you prefer your things to be in the file system, or then in some never-ending hybrid state, them being always within the file system, but with cryptic names and not accessible anymore but thru some dedicated database application; for information management / office workflow of office documents, that might even be inevitable in the end (or then, the only other alternative being to put your things into a monster database, no traces of them even left within the file system) - but for media management of all sorts, the philosophy behind Adobe LR is arguable, to say the list - and the FPV developer has correctly realized this, since hardlinks would not be that helpful in LR, but with file-system-based pic applications, they can be invaluable IF, as said before, the (main or third-party) applications don't break the hardlinks (or restore them immediately after breaking them).
(FPV unfortunately has the worst - and worst by miles, that is - file browsing functionality I have ever encountered anywhere, both for browsing as for targeting (moving / placing the hardlink) means, so as a picture file manager or even just (general) picture browser (except for immediate access to just-downloaded, new directories), it's almost unusable, and the usefulness of its hardlink-creation functionality should be intensily hampered by the fact that navigation to the respective target locations in which to then create the hardlinks, is an almost incredibly difficult chore. But then, it preloads pictures, and so, while there is no further real speed advantage for browsing .jpg and similar pictures with it, over some other program (FSIV, DO, XY), it's evident that for multi-mb raw files, the speed advantage is upheld, to a degree, depending also of course on the speed of your respective storage medium.)
Be that as it may be, even for just looking at picture, listening to music, etc., hardlinks can be extremely helpful. Just let me say here upfront that I know that most media files come with more or less numerous possibilities of storing metadata, so there is always the alternative to exclusively rely on those instead, and I acknowledge the fact that before deciding to use hardlinks instead, you should compare the different ways of doing things indeed. But let me explain the advantage of hardlinks over traditional .lnk files (symlinks identical to them?), even for "consuming":
If you link to your files within another folder, that's for categorizing the same (media) file under different aspects, of course: the same picture under "landscapes under rain" and under "Camargue trip Summer 1998", etc., etc., the same jazz/soul... tune under the name of the tune ("Summertime"!, "I love you more than you'll ever know"!) and under the name of the artist - I admit that my music examples aren't that totally pertinent since you could use stored searches instead, to some degree, since here the necessary "tags" would even be in the respective file names, most of the time, but even then, there are variants in spelling - let alone the often almost incredible spelling error in YT tunes which clearly show that the uploaders in question don't know a bout about their hot goods.
I also admit that in many cases and/or for many people, tagging would be preferable to multiple directory entries, i.e. entries into multiple directories, but here again, we've got the old problem that either tags aren't "readable" (ie that the files aren't sortable) but within special, dedicated software (except, partly, for tags in files' alternate data strings (ADS), but they present a certain speed problem), or that you'll get quite ugly and especially quite long file names (if you do the tags there), let alone the fact that then you will not have got a tool yet by which to really well manage / administer those file name tags (hundreds of stored searches? that's not that practical, after all); XY for example comes with a some tag-maintenance/retrieval functionality, but that's for its proprietary tags if I'm not totally wrong here, no such thing for tags in file names (except for mass renaming, ubiquitous in good file managers - as I said elsewhere in this forum, the free FC even has got one of the very best (and intuitive) bulk renamers on the market).
But back to hardlinks vs traditional .lnk files (symlinks now?) in traditional browsing situations; the same is true for office documents and similar. So you will have created traditional links/symlinks or aliases/hardlinks to/of the necessary files in your current "target" folder, let's say a project folder for some work, or simply the "person x" folder, your files being originally stored by (chronology and/or geography of) shootings. You want to look at these pictures grouped by folder, you want to use core/reference data to be included in your work.
With .lnk files (and very probably with symlinks if really they are something different now), the "opening" of any such file here in your "target"/project/special folder will immediately trigger the file manager (or FSIV and the like) to display that "origin" folder of the file you just "opened", which means your "browser", for every (?) non-hardlink file entry, switches to the respective "home" folder of that file, so any "opening" of a linked file anywhere "breaks" your browsing. (I don't know how FPV behaves in this situation: since with very few coding "intelligence" it'd be perfectly possible to NOT do that unwanted shift, it's possible that its developer has implemented the functionality to just follow the link but without switching to an unwanted directory here.)
Which clearly shows the superiority of hardlinks for any such (leisure or work) browsing situation: You stay in your "project"/"current" folder, independently of the original storage location of the very first entry/listing of your file, since for hardlinks (only?), any listing is the "original" one; in other words,
if you want to implement your third-dimensionality of file access by file-system means, you seem to be in need of hard links.
Since with file-name-tagging (ie tagging within the file names), which is another alternative, there is no practical implementation of a tag tree in any file manager, picture file browsers and the like; at least "frontend" for file-name-tagging exists indeed, but it's external again to your file manager / picture manager / etc. (just as all the more traditional "tag tools" are): it's TagSpaces, 39$, but I consider it illogical to have file-name-based tags which then must be managed/administered, and accessed/benefitted-from outside of your file management and media browsing workflow: You'll browse from within your current folder displayed by your file or graphics-media manager (office: any file manager, pics: DO, XY, FSIV and others), so if you wanted to do it by tagging instead of folder navigation, you'd nee that functionality there... or then, tagging applications would need to implement the necessary media-file display functionality, which is even less realistic, considering the relevant quality/speed requirements in its realization, let traditional alone navigational needs which by this would not vanish but aren't there: any such setup which forces you to use a tag tool (even incl. satisfactory display), and a navigational (file system folder) tool concurrently, cannot be said "ideal", while a traditional browser (DO, XY, FSIV) is obviously much better overall, once the three-dimensional file access problem in its folder structure has been resolved.
This includes the necessity for very fast (!) creation of the necessary "metadata", be it hardlinks, tags in ADS or any other means. As said, those ADS tags come with a slight speed problem even on retrieval (just try in x2 or with a dedicated tool), while both tags-in-file-names (by the same retrieval technology used in "Everything", ie IF that technology is used for retrieval, not so in other cases) as hardlinks (they are just alternative entries in the file table) are instantaneous; but another problem lies in reducing the time which you need to create hardlinks, and here the navigational ease (or lack of it, see FPV above) plays a prominent role: Ideally you will have more than just one tree and/or list pane at your disposal (as in generic file managers where you have at least two of them, the "current" and the "target" one, more so in DO, doubtful in x2 (additional but non-live panes), but it's not that easily possible in XY and others (just "tabs" for alternative folders but which can be used as link targets by some additional scripting, without "opening" them (which for link creation isn't necessary anyway); in fact, if you have some list, that list could have some 50 or more (depending on your screen resolution) entries concurrently visible, any of which could be a possible link target (list of the multiple folders within a parent folder), or even better, a partly-expanded tree structure (so that the folders listed would not be necessarily sibling folders); just a dozen or so tabs instead, and without easily-readable (ie complete) file names, as possible link targets, isn't the same, far from that...
So here again, and considering its picture display capabilities (you would want to do browsing and link creation at the same time of course, since the need for additional entries will arise from browsing), DO seems to be a rather good solution for quick hard link creation for pictures and other media files or even in general, since a number of n "listers" could contain a considerable number of possible link targets (folder lists), n then being the number of groups of folder siblings; the attentive reader will discover the high interest of "hoisting" in some text databases (like UltraRecall and others) since in such a setup, you'll have a multitude of, not flat-lists, but of possibly-expanded, or expandable, sub-trees, which multiplies the number of readily-available link-targets (ie locations for positioning the link or alias), even though over there, you'll have to "open" these additional tabs first, but then, navigation to the desired link target is almost instant.
Of course, there's always the problem of returning to the "active" folder, and there, to the "active" element (picture, office file, whatever); it's desirable that after each link creation, you'll immediately get there again, in order to smoothly continue your browsing / link making. With tabs and multiple visible panes, this condition is regularly met; not so in a single tree like in FSIV where each (necessary) "selection" of some other tree entry does not only invalidate the selection of your "current" folder (which you browse, and from which you create the links or aliases=hardlinks), but worse, when you (manually of hopefully by script) get back to that, you then have to identify your current file anew, which for folders with hundreds of pictures in them is almost impossible, "manually" ie visually, and scripting with regards to FSIV isn't evident at all, elements in FSIV often not being identifiable.
This leaves us with DO as our first choice, and with XY as our second choice: Both are brilliant with picture display (and probably with video clips, too?), and both offer multiple concurrent link targets (mostly sibling folders), DO displaying them directly, XY hiding them behind tabs (if you don't use the tab folder = parent folder as link target, you must open the tab first, then close it again, in order for the target pane becoming available for other targets again).
Full automatization isn't possible since most of the time, you will first "create the link" (ie store the path of the file to be linked), then designate the target pane/tab (ideally by 1-key shortkeys, and which also opens the tab if it's a tab, not a pane), then manually navigate to the target folder in that pane (arrows up/down), then trigger macro 1 (see above) which creates the link/alias within the target folder (without opening it), and which then also closes the tab again, in the tab situation, but it's evident that in such a workflow, creation of each link/alias will take less than 10 seconds IF you limit the possible targets somewhat, ie if you don't try to switch to "exotic", non-easily-reachable targets, too, but if you try to group your link creation in a way, setting up some "combination" of link targets for some work session, then set up another combination of panes/tabs for some other work session; it becomes evident here that the possibility to store these groups (incl. their current open/closed state) becomes very important, in order to get them immediately available for similar work sessions later on, without having to tediously recreate them again and again (I don't know if such "layouts" of panes and/or tabs are available in the programs mentioned here).
Also, it's evident that link targets you need again and again (for example current projects, in office use, or "standard" picture folders, or even "standard inboxes", ie inboxes in higher-up sub-folders from which then only you will do the more precise distribution of the links/aliases further down into the "real" target folders, later on), should be immediately accessible all the time, either by shortcuts or then in some "standards" pane grouping them, and in which those standard target locations then would be targetable by the very first character of their name (so in order to avoid mishaps, automatic alphanumeric sorting in that pane would be welcome), and by this, even a simple 2-key macro could do all the work for these (intermediate or final) standard target locations: some F-key as trigger, then a...z or 1...0 for up to 36 locations not needing any navigation to access them. (It would be ideal to even have these "standards" multiple, at the very least one such set for office use and another one for pictures, another one for classical music, another one for jazz music, and for the pictures, I could easily imagine several standard sub-lists, too; technically, no problem: Just store them grouped in some special folder identified by your tool), and the special command will work on the only one visible one of these special lists, at any given moment.)
From the above, it also becomes evident that the "aliases" is not so much about other file names, but, exclusively in most situations, about other locations: the same file name, but in multiple folders. And from this, you can imagine two quite simple (non-technical but user-interaction) intermediary (ie waiting for better, technical) solutions to the last-file-standing-and-then-falling (sort of friendly-fire) problem described above: The lesser solution would be to systematically add some special character to any link/alias, while not renaming the original file entry in the same way. Then you will never delete any "last" file inadvertently, wrongly assuming it's "just another alias", but whenever you then delete a file entry without that special character, you will want to kill the file itself - admittedly, without succeeding in doing so whenever some other alias of it survives elsewhere in your file structure.
The probably better but radical solution would obviously be, to introduce abstraction between file storage and file naming: have some bulk folders for anything new of some sort, you could for example have folders for some file extension, and then subfolders by date (e.g. one new subfolder a year, or per month if necessary by the sheer amount of it (professional photographers and the like)) - and then have aliases, exclusively, i.e. put any file in some (pre-sort) target folder, with its original file name, and then into other such target folders, but the very first (and probably, for most files, unique) target folder will already be a "second" location for the unique file; in this set-up, every file entry in an accessible folder will be an alias, a virtual entry, compared with the original file entries, in the (here: deliberately) non-accessible (non-accessed) storage-only folders. Such a system will be as neat as it get, and should be the future of NTFS (or its successor): Then, Windows can automatically assign cryptic original file names to any file, just like it does it currently do to "special" files, and everything (except the system files that is) will be accessible from everywhere, under any file name you will want to assign to it there, the very first such entry, as said, being the first non-cryptic, "human-readable" file name of your choice.
It's evident that such a system would greatly simplify any further file operation, the "really original", the cryptic, file entries just being there for Windows(') administration purposes, and they would very rarely, if ever, be changed. (Technically, it's easy to do this even now: just run a script moving all your files into such "technical folders" (as you know, their respective physical positions on the harddisk will not change with that "move"; as said, by extension, and with a little sub (whenever more than 1,000 files of that extension, create a new folder for the rest), replacing all original file entries by (hard) links at the same time; ditto for any new files then: any new file creation would trigger a little routine creating it at the "centralized" storage, while creating a link where you create it, and you'll have created and will be maintaining your own, 3-dimensional NTFS system.
Ok, that's not considering the "some applications kill hard links" problem described above, neither do I presume anybody will follow my advice here, and I didn't treat the impending recursion problem with folders, apart from and to begin with the fact that I haven't mentioned the problem that you cannot apply hard links to folders anyway but must do it differently for them, but it's evident that the current - virtual-only anyway, as explained above - relationship "1-file-to-1-filename" paradigm in Windows (and prevailing in NTFS) is junk (as is the - equally virual-only - separation into "files" and "folders", too, but explaining this would double the text amount here); and that MS should finally do their so long-overdue homework.
It's all about providing three-dimensionality to a file system, while at the same time avoiding to set up any database - outdoing what the "Everything" indexing does - as the file system's sidecar, this will for avoidance being there for obvious speed and reliability reasons and being perfectly understandable... but perfect three-dimensionality (and including folders, not treated here) is already possible with NTFS if organized differently, and the one-file-referenced-trans-drive problem should be overcome with a "database" (ie with a simili-database, just like the MFT is just such a simili-database, and the necessary change indexing and -processing) indeed.
In a word, what we need is a spiced-up
NTFS with handshaking for synching, but in the meantime, our homemade possibilities are far from inexistent; especially media home storage should probably be made with DO and then some little macros for speeding up the link creation process, as described above (and attending what they will implement internally instead), since browsing / viewing AND creating of multiplicity is seemless then - for bigger storage needs, the question would be if a big NAS or similar can be set up or not, with one shared, big MFT, so that for Windows' / hard links' means it's all one drive. And remember, hard links are the file system itself, while metadata / ADS are not stored there but will have to be retrieved separately, hence their incompatibility with large datasets when not indexed - but indexing them for immediate retrieval should always be possible, so there are alternatives.
