Talk:Symbolic link

message: The question of the effects of read, write and execute permissions as seen by the user of the materials accessed via the symlink, and the user of the same materials accessed directly needs to be addressed. Questions such as "If I write protect the symlink, does that write protect the content at the target of the symlink, even if the target is actually writable if accessed directly?" will be on some visitor's minds. Such as mine. :) Fyngyrz (talk) 16:30, 22 December 2015 (UTC)
thread_title: Permissions Information

message: As this is Wikipedia article and not a how to, I came here looking for the history of symbolic links. While there is some talk about their use in minis (thank you), I would value  more detail on the history, development and theory.  But please, do not degenerate into which OS intended it first contest.  Thanks.    — Preceding unsigned comment added by 2001:4898:80E0:EE43:0:0:0:2 (talk) 16:06, 14 August 2014 (UTC)
replies: text: The ITS 1.5 Reference Manual from 1969 says there were symbolic links.  The 1.4 manual from 1968 does not. Lars Brinkhoff (talk) 13:40, 24 May 2018 (UTC)

text: The Multics paper "A General-Purpose File System For Secondary Storage" from 1965 describes symbolic links.  Note that Multics wasn't operational until 1967. Lars Brinkhoff (talk) 13:45, 24 May 2018 (UTC)
thread_title: History Request

message: The article currently states: 
Vista has a limit of 31 symbolic links in a single path.
This implies that a directory (C:\Temp) can only contain 31 symbolic links (e.g. C:\Temp\Dir1, C:\Temp\Dir2, etc.). According to Microsoft's documentation, "[t]here is a maximum of 31 reparse points (and therefore symbolic links) allowed in a particular path." A "reparse point" is essentially a symbolic link or directory junction. As such, Windows 7 and Vista are limited to a chain of 31 symbolic links or junctions.
I believe the above quotation should be replaced with the following line:
Windows 7 and Vista support a maximum of 31 reparse points (and therefore symbolic links) for a given path.
--216.148.0.72 (talk) 01:05, 30 May 2012 (UTC)
thread_title: Misleading Vista/Win7 Comments

message: please use simple language to describe the problem. there is no need to use many foreign words. wikipedia aims to be understood by everyone not just a 'choosen few'.
it would be perfect if you would use no technical english even for tech articles.
--212.202.37.226 17:10, 5 Jun 2005 (UTC)
thread_title: No Eleete Language

message: On another note,
It seems that vista does not have true support for symlinks: http://slashdot.org/articles/06/11/19/018256.shtml
Perhaps this should be corrected in the article.
:You're right: Vista does not have 'true support for symlinks'. Vista can't even connect to a native Unix file system at all! 
:What Vista has is support for Symbolic Links, implemented as a component of NTFS. Sadly, Unix systems which connect to NTFS file systems don't have true support for NTFS Symbolic Links, because they don't understand the symbols.
:Yes Symbolic Links are a component of NTFS. Yes, you have to load all of the current version of NTFS to get this feature. Yes, the NTFS Symbolic Link components only come with Vista. No, you don't need a new version of NTFS: NTFS allows you to add features.
:And finally, Yes these symbolic links allow you to have different file and user permissions for each symbolic link. Nifty feature, yes?
::Note: Windows 2000 had Windows SFU, which had NFS and symlinks 218.214.18.240 (talk) 06:02, 24 November 2007 (UTC)
thread_title: Vista and symlinks

message: The following sections have been removed:
:Symbolic links can be remapped to allow locations of files to be addressed in a consistent manner, even though the physical location of the file may vary.
I don't think this is true.  Symbolic links are immutable (they cannot be changed), however they can be removed and then a new symbolic link can be created in their place.
:Using the 'ls -l' command, which is standard on these systems, a symbolically linked file might look something like this:
:
:lrwxrwxrwx    1 jbailey  users         4 2003-02-07 16:49 link -> file
:
:The 'l' in the first column is a hint that this file is a symbolic link.  The information at the furthest right indicates that this file is called 'link', and that when you access it, you will see the contents of 'file'.
This doesn't belong in this article.
:Symbolic links to directories can be dangerous for unaware programs working with directory trees. At best they can cause endless looping as well as pathname buffer overflows leading to crashes or dangerous malfunctions. At worst, deleting a directory tree will lead to the content of the symlinked directories being deleted as well. Unix tries to protect against this behavior to some extent by disallowing to destroy a directory symlink using the remove-directory (rmdir) system call, hence symlink-unaware programs will generally fail after trying to delete the first such link.
This may be a valid point, but I question its pertinence.  At the very least, it should be reworded.  Unix-like systems take no such precaution: 'rmdir' operates on the directory entry and ignores its contents.  Directory trees cannot usually be deleted in a single action, either.  A program must recurse through the tree, deleting all of the files in a directory, then removing the directory itself.—Kbolino 01:55, 7 January 2006 (UTC)
thread_title: Clean-up

message: I just learnt that Windows 2000 (and above) does support symbolic links but is not well-documented.  I was researching a problem with missing files and read this article - http://shell-shocked.org/article.php?id=284 - which is fairly descriptive about how Windows works with Symbolic links.
gv —The preceding unsigned comment was added by Guhanv (talk • contribs) 12:34, 26 April 2007 (UTC)
replies: text: No, Windows 2000 does not support symbolic links (except as shortcuts and mount points). NTFS 3, which is the default file system of Windows 2000, provides generic support for symbolic links, but Windows 2000 has no way to create or follow them. As the reference points out, you can use shortcuts or mount points "like" symbolic links. Or you can add support for symbolic links to Windows 2000, because Windows 2000 uses an extensible file system and an extensible command shell. But the same was also true of DOS 3.1 (david) 218.214.18.240 11:10, 10 June 2007 (UTC)
replies: text: Actually, Windows 2000 does support symlink-type functionality, but for directories only, not files; see NTFS Junction point.  Windows Vista implements proper symbolic links for all types of file, including across network shares; see NTFS symbolic link.  All this is now in the article.  And no, the same was not "true  for DOS 3.1" (assuming you mean WIndows 3.1, which used DOS 6 or thereabouts): this functionality is all implemented using NTFS reparse points, of which FAT had no equivalent; WIndows 3.1 did not support NTFS.  -- simxp (talk) 18:24, 3 May 2008 (UTC)
replies: text: Right, Windows 2000 does support 'symlink-type' functionality, rather than symlinks. Windows 2000 also, like DOS 3.1, has an extensible file system that allows you to add features like symlinks, which has been done in Vista. DOS 2.2 had a replaceable file system, but DOS 3.1 added significantly to the operating system capability, making it possible to implement symlinks without replacing the whole file system.218.214.18.240 (talk) 04:40, 5 September 2010 (UTC)
replies: text: By the way, Windows supports variable shortcuts using environment variables. I haven't seen anybody using this with Symbolic Links, but that also looks possible, linking through a GUID and the registry.218.214.18.240 (talk) 04:46, 5 September 2010 (UTC)
thread_title:  Windows supporting Symbolic Links 

message: The statement that "Cygwin ... creates Windows shortcuts (.lnk files)" seems to be incorrect or outdated.  —Preceding unsigned comment added by 145.94.50.9 (talk) 15:46, 14 January 2011 (UTC)
thread_title:  Cygwin symlinks 

message: "The misuse of soft links can be a cause extreme irritation in many subjects. Doctors report a significant increase in blood pressure, body temperature, and elevated vocal ranges. Persons with a history of heart conditions should refrain from the use of softlinks without first consulting with their physician."
What does this have to do with softlinks?  —Preceding unsigned comment added by 68.197.165.133 (talk) 06:55, 15 September 2007 (UTC)
thread_title:  Doctors? 

message: So can anyone decisively explain the differences between filenames, shortcuts, hard and symbolic links, and the data they represent? —Nahum Reduta 05:10, 2 December 2007 (UTC)
thread_title:  [[Haddock's Eyes|White Knight ]] Through the Looking Glass 

message: Why was the concept of symbolic links invented when there is already the concept of hard links? --Abdull (talk) 18:49, 7 August 2008 (UTC)
replies: text: Hard link#Limitations of hard links -- simxp (talk) 11:36, 18 August 2008 (UTC)
thread_title:  What's it good for? 

message: Note that Windows Shortcuts may contain a relative path, or an incomplete path.
I don't want to see a full explanation of Windows Shortcuts here, just to avoid subtle technical errors.218.214.18.240 (talk) 05:25, 5 September 2010 (UTC)
thread_title:  relative path 

message: In the intro it is claimed that symbolic links were already present in 1978 in mini computer OSs from DEC. I knew one of them (RT-11) quite well and it did not have symbolic links on the file system level. The latest versions of RT-11 knew something like command aliases, but no symbolic links.
I never used the other mini computer OS RSTS (also created by DEC), but according to the RSTS page it was similar to RT-11.
I think the claim should be modified.
Treutwein (talk) 09:35, 24 January 2011 (UTC)
thread_title:  DEC mini-computer OSs & Symbolic Links 

message: OS/2 does indeed support symlinks (not hardlinks) via extended attributes. These work on HPFS and JFS volumes, though I am not sure of FAT volumes, as EAs are stored differently. The reading and proper interpretation of such symlink data is dependent upon the application, however. Linux applications, ported using GCC, for the most part understand symlinks perfectly well.
The section pertaining to OS/2 as it now stands is completely irrelevant, as WPS shadows are not symlinks of any sort, as they have nothing to do with the filesystem whatsoever, and are only understood by the WPS. I suggest removing this mention entirely or at least referencing it in the context of WPS constructs. I am happy to provide language to re-work the OS/2 section.
LewisR (talk) 23:11, 8 January 2012 (UTC)
thread_title:  OS/2 has POSIX-like support for symlinks; Shadows are unrelated 

message: A directory is a special type of file, so the many references to "file or directory" and variations thereof could be replaced by simply "file" for brevity. l0b0 (talk) 10:44, 7 August 2012 (UTC)
thread_title:  "File or directory" is redundant 

message: The Overview sub-section is not exclusively about Windows, so it should be moved out of the Microsoft Windows section.
l0b0 (talk) 11:24, 7 August 2012 (UTC)
thread_title:  "Overview" section doesn't exclusively treat Windows