Talk:Hard link

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

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)[reply]

Point to directory[edit]

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)[reply]

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)[reply]
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)[reply]

Drawbacks[edit]

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)[reply]

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)[reply]

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)[reply]
  • 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)[reply]

NTFS to and/or from?[edit]

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)[reply]

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)[reply]

locating hard links on a system[edit]

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)[reply]

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 

dirname
dirname/.

and may have more: 

dirname/subdir1/..
dirname/subdir2/..

to exclude directories from the result do this: 

find -links +1 -not -type d

Jasen betts (talk) 10:57, 16 April 2009 (UTC)[reply]


(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?[reply]

No tools should be used for that, doing that automatically could cause problems: if the file is altered they all will change. Jasen betts (talk) 10:45, 16 April 2009 (UTC)[reply]

A script I use for this purpose is ln-r; it works fine on Linux, but also on Cygwin, running on Windows XP with NTFS, even on remote file shares: 

   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

Rp (talk) 10:11, 7 January 2010 (UTC)[reply]

Open files that have been 'deleted'[edit]

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)[reply]

History[edit]

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)[reply]

They were in Unix right from the start, i.e. 1970.[1] Rp (talk) 14:49, 24 March 2010 (UTC)[reply]
  1. ^ [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
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)[reply]

Windows 2000[edit]

fsutil is not available for Windows 2000, it exists only for Windows XP and Windows 2003 Server.

What endless recursion are you talking about?[edit]

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)[reply]

Good point - can you think of a concise way to amend the article text? Rp (talk) 23:14, 26 March 2010 (UTC)[reply]

POSIX Compliance?[edit]

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)[reply]

Also, the following sentence makes it sound like Windows NT is POSIX-compliant:

"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[1] 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). - 193.84.186.81 (talk) 03:36, 28 July 2011 (UTC)[reply]

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)[reply]
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)[reply]

"FAT does not"[edit]

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 203.206.162.148 (talk) 09:56, 9 June 2011 (UTC)[reply]

I don't know about that but if you could add it to the article (with references) that would be nice. - 193.84.186.81 (talk) 03:41, 28 July 2011 (UTC)[reply]
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)[reply]
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". 203.206.162.148 (talk) 04:20, 3 May 2012 (UTC)[reply]

links[edit]

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)[reply]

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)[reply]

External links modified[edit]

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:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

checkY An editor has reviewed this edit and fixed any errors that were found.

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 03:53, 30 October 2017 (UTC)[reply]

Works, but that information's now on their home page, so I linked there. Guy Harris (talk) 04:00, 30 October 2017 (UTC)[reply]

0 hard links does not mean the file is gone![edit]

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)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Hard_link&oldid=1198435991"