Talk:Hard link

message: This article is really pedantic.
Instead of "a reference, or pointer, to physical data on a storage volume", why not just say "a reference to a file"?
Why not say "file" or "file inode" instead of "physical data section"?
It should say that you can't create (additional) hard links to directories.  Are there any systems where that is not the case? —Preceding unsigned comment added by PGibbons (talk • contribs) 
Would not it be nice to have some table here showing which filesystems are hard-link capable?  — Preceding unsigned comment added by 209.132.186.34 (talk) 09:07, 6 March 2013 (UTC)

message: This article starts saying that a hard link can point to a directory however the Symbolic link page says that it can't, only a symbolic can. Which one is right ? 187.26.202.99 (talk) 13:30, 19 June 2009 (UTC)
replies: text: This article states that generally hard links to directories are not permitted.  This avoids some inconsistencies caused by the implicit assumption that the file system is a tree (if a subdirectory is linked to in two others, which is the parent directory?). There are a couple of exceptions - MacOS is simply a particular instance where it is done differently.  Older systems frequently allowed hard linking by the superuser - the origins to this are before the mkdir ssytem call, and the mkdir executabel created directories itself.  Both articles appear correct me, although the symbolic link article is proably makign an overgeneralisation as presentign a general ruel as a universal truth, it does present enough that is needed for the subject matter of that article. CrispMuncher (talk) 21:46, 19 June 2009 (UTC)
replies: text: What the ln command disallows is creation of an additional hard link to a directory by a non-superuser, because of the cycles this may create. Rp (talk) 10:23, 29 December 2009 (UTC)
thread_title: Point to directory

message: How is it a drawback that hard links can only be created whithin a single partition? It is a drawback as much as not writing red is a drawback of a blue pen. If partition 1 holds physically data A, to which filename A (in partition 1) points, and partition 2 contains filename B, which is a hard link to data A... how would mounting and unmounting of partition 2 be handled? Data A is defined as deleted when all hard links to it are removed. If filename A is removed, and B is not, but partition 2 is unmounted... what happens to data A? Is it accesible again when partition 2 is mounted? And if partition 1 is unmounted, but partition 2 is not... would filename B be a dangling link, as if it where a symlink? And if another partition is mounted in the mountpoint partition 1 had? Now the link would have to "remember" physical partitions, not filesystems (as the soft link does)... bizarre and silly. —Preceding unsigned comment added by Isilanes (talk • contribs) 
:While it might seem blatently obvious to those that understand computers particularly well enough to get by on their own, it may not seem so for those which aren't. Suppose you never saw a pen before, if you were to see someone writing in red instead of blue, you might wonder why you can't write in red as well. --Mike 04:29, 2 December 2006 (UTC)
replies: text: To ignore links is sometimes necessary to avoid endless recursion.
This is irrelevant because only files can be hard-linked, not directories.
To repeat the above question, are there systems where you can hard-link
directories?
--- Dse 06:32, 2 January 2007 (UTC)
replies: text: Windows can have hardlinks accross partitions just fine.  And while you can not use hard-links on directories, they are related to junctions, in effect hard-links for directories. 4.160.246.72 21:32, 5 July 2007 (UTC)

text: * This is not possible unless you allow filenames on one partition to point to data in another partition, which is a severe negligence (unless they are soft links). If filename A in partition 1 and filename B in partition 2 are both hard links to data D... in which partition does D physically reside? If the answer is "both", then the files are not hard links: they are two regular files. If the answer is partition A but not B, then all hard links are not equivalent (which is a feature of actual hard links). In that case, A would be a regular file, and B would be a soft link. For example, would removing filename A delete the actual data D? It should, because for the filesystem the last link to the data (filename A) has been deleted (partition 2 could even be unmounted). But then, filename B would be pointing to an empty location (just like a soft link). — isilanes (talk|contribs) 15:51, 6 July 2007 (UTC)
thread_title:  Drawbacks 

message: For Windows, do both source and destination need to be NTFS? Or just source? — 123.243.204.44 (talk) 01:42, 18 November 2007 (UTC)
replies: text: Hum, the article says (and already did so when you posted) "On Microsoft Windows, hard links can be created only on NTFS volumes", and "Hard links can only refer to data that exists on the same file system. --Jerome Potts (talk) 09:50, 24 January 2008 (UTC)
thread_title:  NTFS to and/or from? 

message: is there a way to find out whether there are any multiple hard-linked files on a system? --Jerome Potts (talk) 09:54, 24 January 2008 (UTC)
thread_title:  locating hard links on a system 

message: I have removed some comments from the main article attributing this behaviour to links.  I don't see any direct relationship between the two.  Contrary to the earlier revision there is no technical reason why a file system cannot support an open file that has been 'deleted' and yet still not support hard links. CrispMuncher (talk) 21:45, 8 July 2008 (UTC)
thread_title:  Open files that have been 'deleted' 

message: When did hard links first become available in unix and windows? Jasen betts (talk) 11:08, 16 April 2009 (UTC)
replies: text: They were in Unix right from the start, i.e. 1970.[http://cm.bell-labs.com/cm/cs/who/dmr/hist.html The Evolution of the Unix Time-sharing System, by Dennis M. Ritchie, Bell Labs Rp (talk) 14:49, 24 March 2010 (UTC)

text: When ln worked on directories, unlink also worked on them.  So it wasn't hard to delete a hardlink, or orphan a directory, but you had to be superuser.  A directory orphaned that way would have its contents show up in LOST+FOUND on next fsck.  Modern kernels seem to prohibit both actions.  Technically, you can still create hard links to directories with the mkdir command, which hardlinks the parent directory to .. in the new directory and "." links to the directory itself.  However, that may be a pedantic technicality, as some filesystems implement .. and . virtually without hardlinks. A side effect of this hard linking is that you can tell how many subdirectories a directory has by looking at its hardlink count. ssd (talk) 20:27, 5 March 2021 (UTC)
thread_title:  History 

message: If this was the reason to disallow hard links for directories then symbolic links would be disallowed for directories too!
You can create "endless recursion" with symlinks just as easy. Thats why we have the ELOOP error.
In the case of hard links you could use some other limit (e.g. ENAMETOOLONG) and good bye to the infinite recursion.
The real problem with the hard links for directories is much more deep and obscure.
It is such that can lead to very bad consequences that can not detected or prevented by the OS.
I will illustrate the problem here:
Imagine that you are allowed to create multiple hard-links to directories. Then you do the following
 mkdir /A
 mkdir /B
 ln /A /B/A  (create a link to A inside B)
 ln /B /A/B  (create a link to B inside A)
At this point there are 2 variants:
:a) you are not allowed to rmdir non-empty directories even if they have more than 1 hard links
:b) you are allowed to rmdir non-empty directories as long as they have more that 1 hard links
in case a) the 2 directories are now unremovable, which is a VERY major problem and can not be prevented.
in case b) do the following:
 rmdir /A
 rmdir /B
at this point both the directories remain undeleted because they still have 1 hard-links each.
but they are no longer accessible, and so all the disk space allocated in them is lost forever
(you could have other files/dirs inside that are lost too).
this is also a VERY major problem that can not be detected or prevented.
—Preceding unsigned comment added by 77.70.56.64 (talk) 00:23, 26 March 2010 (UTC)
replies: text: Good point - can you think of a concise way to amend the article text? Rp (talk) 23:14, 26 March 2010 (UTC)
thread_title:  What endless recursion are you talking about? 

message: In the intro to the section, it is mentioned that POSIX compliant OS's have hard links. FreeBSD is not POSIX compliant, however it, along with the other BSD derivatives support hard links. Is there a better way to phrase this?  —Preceding unsigned comment added by 76.116.34.189 (talk) 06:53, 12 November 2010 (UTC)
replies: text: Except that it was POSIX-compliant: it had a POSIX interface - see e.g. POSIX for Windows. Rp (talk) 07:33, 28 July 2011 (UTC)

text: If an OS is POSIX-compliant, it must support hard links on its file system.  If an OS supports hard links on its file system, it's not necessarily POSIX-compliant.  To pick an extreme example, Version 6 Unix wasn't POSIX-compliant (the original POSIX was more like Version 7 Unix), but supported hard links. Guy Harris (talk) 08:59, 19 November 2013 (UTC)
thread_title:  POSIX Compliance? 

message: In order for this article (and symbolic links) to make sense, they should explain what a link is. Links came about with the innovation that a filename need not actually be associated with a file, it's may simply be associated with the directory entry for a link to a file (or segment). Then term "hard link" needs to be understood as a back formation invented after symbolic links were invented. This article should be called "Link" because that's what this describes. Symbolic links were invented because they are convenient to solve some of the problems with multiple links to a segment. The way the articles are written, they throw away the interesting parts of all this. Newbies coming to read about this should learn how to think about it. 68.174.97.122 (talk) 03:36, 7 October 2013 (UTC)
replies: text: I don't understand your objection. I had the exact same criticism and rephrased some things in the article to answer to it; in particular, the first two sentences are supposed to say exactly what you're saying here, a little more concisely. You may be correct that more explanation may be needed, feel free to give it a try. Rp (talk) 17:09, 7 October 2013 (UTC)
thread_title:  links 

message: Hello fellow Wikipedians,
I have just modified one external link on Hard link. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
*Added archive https://web.archive.org/web/20110302053606/http://www.alldup.info/en_alldup.htm to http://www.alldup.info/en_alldup.htm
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 03:53, 30 October 2017 (UTC)
replies: text: Works, but that information's now on their home page, so I linked there. Guy Harris (talk) 04:00, 30 October 2017 (UTC)
thread_title:  External links modified 

message: Some misinformation has crept into this article, which now states in several places that when the last hard link to a file is removed, the file is deleted and its space is freed. This is incorrect. On POSIX(-like) systems, as long as a process has a file open, it will continue to exist, even when no hard links to it remain. What is more, these systems essentially rely on this behaviour for their operation, e.g. this allows software to be updated while the software is in use. Rp (talk) 10:07, 21 May 2021 (UTC)
thread_title:  0 hard links does not mean the file is gone!