|WikiProject Computing||(Rated Start-class, Mid-importance)|
|WikiProject Computer science||(Rated Start-class, Low-importance)|
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)
Point to directory
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 ? 22.214.171.124 (talk) 13:30, 19 June 2009 (UTC)
- 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)
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)
Under "Drawbacks of hard links" someone wrote:
- 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)
- 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. 126.96.36.199 21:32, 5 July 2007 (UTC)
- 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)
NTFS to and/or from?
- 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)
under posix you can do it using find like this:
find -links +1
most of the result may be directories which typically have at-least two links
and may have more:
to exclude directories from the result do this:
find -links +1 -not -type d
(assumed Jerome Potts 09:54, 24 January 2008 (UTC)) Which tools should be used for different OS-es to search duplicate files and save space by creating hardlinks?
sh> echo a > a sh> echo a > a2 sh> echo b > b sh> ln-r a a2 b sh> echo c > a sh> cat a a2 b c c b
Open files that have been 'deleted'
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)
When did hard links first become available in unix and windows? Jasen betts (talk) 11:08, 16 April 2009 (UTC) early linux kernels allowed creating hard links to directories, but they were impossible to delete using normal means, my experience was with linux 0.95.x Jasen betts (talk) 11:08, 16 April 2009 (UTC)
- [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
fsutil is not available for Windows 2000, it exists only for Windows XP and Windows 2003 Server.
What endless recursion are you talking about?
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.
- Good point - can you think of a concise way to amend the article text? Rp (talk) 23:14, 26 March 2010 (UTC)
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 188.8.131.52 (talk) 06:53, 12 November 2010 (UTC)
"Hard links—that is, multiple hard links to the same file—are supported by POSIX-compliant and partially POSIX-compliant operating systems, such as Linux, Android, Apple's Mac OS X (see Time Machine), Windows NT4 and later Windows NT operating systems."
I know Windows NT was in some ways inspired by Unix and adopted some of its concepts but I do not think it is in any way appropriate to call it "POSIX-compliant" (even partially). - 184.108.40.206 (talk) 03:36, 28 July 2011 (UTC)
- 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)
- 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)
"FAT does not"
That is to say, Windows does not on FAT. And if you do create a hard link in a FAT file system, Windows considers it to be an error, and Scandisk/Checkdisk will attempt to correct it. — Preceding unsigned comment added by 220.127.116.11 (talk) 09:56, 9 June 2011 (UTC)
- I don't know about that but if you could add it to the article (with references) that would be nice. - 18.104.22.168 (talk) 03:41, 28 July 2011 (UTC)
- Certainly FAT's design doesn't preclude multiple hard links to a file, but "Windows" is not a very specific term here. Where in Windows is this error generated? In a FAT-specific subsystem? Rp (talk) 07:47, 28 July 2011 (UTC)
- In Scandisk/Checkdisk. Scandisk/Checkdisk will identify as errors, multiple directory entries (hard links) which point to the same cluster (FAT entry). Windows/DOS will have other problems with hardlinked files (unless extended to cope), but the process which notices that there are multiple links and lists them as errors is Scandisk/Checkdisk.
- The distinction is of present interest because the FAT file system is presently widely used by OS and embedded software which is not DOS nor Windows. It is of historic interest because there were file systems which implemented Hard Links on FAT partitions.
- However, it can be simplified by making a linguistic distinction here: FAT is the system of data organisation, not the system which uses that system. There was never a "FAT system" in DOS or in Windows, the way you would install NFS or XFS, so it doesn't even make sense to say "FAT does" or "FAT does not". 22.214.171.124 (talk) 04:20, 3 May 2012 (UTC)
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. 126.96.36.199 (talk) 03:36, 7 October 2013 (UTC)
- 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)