So Win7 supports them, eh? What are they and what does Windows (and MS) call them? How do I make them?
Symlinks?
- Thread starter vefatica
- Start date
---- Original Message ----
From: vefatica
To: ESFabian@zenge.org
Sent: Saturday, 2011. July 30. 21:53
Subject: [Support-t-3018] Symlinks?
| So Win7 supports them, eh? What are they and what does Windows (and
| MS) call them? How do I make them?
Read up on the MKLINK command INot MKLNK!).
--
Steve
From: vefatica
To: ESFabian@zenge.org
Sent: Saturday, 2011. July 30. 21:53
Subject: [Support-t-3018] Symlinks?
| So Win7 supports them, eh? What are they and what does Windows (and
| MS) call them? How do I make them?
Read up on the MKLINK command INot MKLNK!).
--
Steve
On Sat, Jul 30, 2011 at 9:53 PM, vefatica <> wrote:
A symlink is a symbolic link, and the concept derives from Unix. In
the Unix file system, a directory entry does not point at a file on
disk. It points to a construct called an inode, which is a data
structure maintained by the Unix kernel, and contains information like
the file's owner, data and time stamps, and permissions mask. The
inode in turn contains pointers to the superblock, which contains
further pointers to the blocks on disk where the file lives.
This permits more than one directory entry to point to the same inode,
so you can have the same file appear in multiple directories, or
appear under different names in the same directory. The Unix vi
editor, for example, appears under three names: vi, ex, and view. Vi
is the full screen editor, ex is a line editor, and view is a
read-only file viewer. All three are different names for the same
program, and what personality the program assumes depends on the name
it was called by.
Links are created by the ln command, like "ln foo bar", so that bar
become another name for foo.
These are "hard" links, with the limitation that they can only exist
within the same file system. Unix keeps track of the link count, so
the actual underlying file is not removed until you remove the last
link to it.
In the MS-DOS days, cross-linked files were a problem CHKDSK would
attempt to fix for you, Under Unix, it's a feature.
NTFS5 supports hard links, and I use them under XP.
A symbolic link is a special file that *points* to another file or
directory. It's conceptually similar to a Windows shortcut, but more
powerful. The OS follows the link and opens the file or directory.
For the most part, this happens transparently. The advantage to
symbolic links it that they *can* span file systems, so a file in the
/usr/bin directory in the /usr file system might actually physically
exist in the /opt file system on a completely different drive. The
use doesn't have to know or care. See
http://en.wikipedia.org/wiki/Symbolic_link for details.
(One quirk is that it's possble to break a symlink: if you remove the
file it points to, the symlink will still exist, but point at a
non-existant object.)
Under Unix, you create them with the ln command with the -s parm: "ln
-s foo bar"
You can create links with a command line program, but under Windows, I
prefer a GUI, and use the freeware Link Shell Extension for the
purpose. It adds right-click context menu entries for Pick Link
Source, Drop Link, and Cancel Link Creation.
Navigate in Explorer to the file you want to link, right click and
choose Pick Link source. Navigate to where you want the link created,
and choose Drop Link. Poof! You have a link.
XP only does hard links so symbolic links don't appear as a choice.
Vista/Win7 supports them, and the choice will be present. If Link
Shell Extension is installed, there will be a visual indicator in
Explorer that the file *is* a link.
Link Shell Extension is here:
http://schinagl.priv.at/nt/hardlinkshellext/hardlinkshellext.html
______
Dennis
A symlink is a symbolic link, and the concept derives from Unix. In
the Unix file system, a directory entry does not point at a file on
disk. It points to a construct called an inode, which is a data
structure maintained by the Unix kernel, and contains information like
the file's owner, data and time stamps, and permissions mask. The
inode in turn contains pointers to the superblock, which contains
further pointers to the blocks on disk where the file lives.
This permits more than one directory entry to point to the same inode,
so you can have the same file appear in multiple directories, or
appear under different names in the same directory. The Unix vi
editor, for example, appears under three names: vi, ex, and view. Vi
is the full screen editor, ex is a line editor, and view is a
read-only file viewer. All three are different names for the same
program, and what personality the program assumes depends on the name
it was called by.
Links are created by the ln command, like "ln foo bar", so that bar
become another name for foo.
These are "hard" links, with the limitation that they can only exist
within the same file system. Unix keeps track of the link count, so
the actual underlying file is not removed until you remove the last
link to it.
In the MS-DOS days, cross-linked files were a problem CHKDSK would
attempt to fix for you, Under Unix, it's a feature.
NTFS5 supports hard links, and I use them under XP.
A symbolic link is a special file that *points* to another file or
directory. It's conceptually similar to a Windows shortcut, but more
powerful. The OS follows the link and opens the file or directory.
For the most part, this happens transparently. The advantage to
symbolic links it that they *can* span file systems, so a file in the
/usr/bin directory in the /usr file system might actually physically
exist in the /opt file system on a completely different drive. The
use doesn't have to know or care. See
http://en.wikipedia.org/wiki/Symbolic_link for details.
(One quirk is that it's possble to break a symlink: if you remove the
file it points to, the symlink will still exist, but point at a
non-existant object.)
Under Unix, you create them with the ln command with the -s parm: "ln
-s foo bar"
You can create links with a command line program, but under Windows, I
prefer a GUI, and use the freeware Link Shell Extension for the
purpose. It adds right-click context menu entries for Pick Link
Source, Drop Link, and Cancel Link Creation.
Navigate in Explorer to the file you want to link, right click and
choose Pick Link source. Navigate to where you want the link created,
and choose Drop Link. Poof! You have a link.
XP only does hard links so symbolic links don't appear as a choice.
Vista/Win7 supports them, and the choice will be present. If Link
Shell Extension is installed, there will be a visual indicator in
Explorer that the file *is* a link.
Link Shell Extension is here:
http://schinagl.priv.at/nt/hardlinkshellext/hardlinkshellext.html
______
Dennis
Anyone care to comment on whether or not there are advantages to using symbolic links to a directory rather than junctions, or vice versa??
On Tue, Aug 2, 2011 at 8:33 AM, Steve Pitts <> wrote:
AFAIK, a Windows junction *is* a symlink, and has been available since
Win2K. What *hasn't* been available is a tool to create them, unless
you buy the Win2K Resource Kit.
Info from MS on Junctions is here: http://support.microsoft.com/?kbid=205524
A free tool to create them is here:
http://technet.microsoft.com/en-us/sysinternals/bb896768
______
Dennis
AFAIK, a Windows junction *is* a symlink, and has been available since
Win2K. What *hasn't* been available is a tool to create them, unless
you buy the Win2K Resource Kit.
Info from MS on Junctions is here: http://support.microsoft.com/?kbid=205524
A free tool to create them is here:
http://technet.microsoft.com/en-us/sysinternals/bb896768
______
Dennis
From: DMcCunney
| Steve Pitts wrote:
|| Anyone care to comment on whether or not there are advantages to
|| using symbolic links to a directory rather than junctions, or vice
|| versa??
|
| AFAIK, a Windows junction *is* a symlink, and has been available since
| Win2K. What *hasn't* been available is a tool to create them, unless
| you buy the Win2K Resource Kit.
Technically, a junction is not a symlink. Junctions are restricted to a single volume, symlinks can cross volume boundaries. Junctions can only reference a directory, symlinks can reference either a file or a directory. From a user's view there is no difference between a junction and a symlink, and I seriously doubt any performance difference. However, it appears that symlinks are preferred, as implied by the report of the ATTRIB command, which uses the letter L to report that a directory entry is either a junction or a symlink.
Ever since the release of Version 5 of 4NT users of JP Software command processors had the MKLNK command to create and delete junctions, and symlink support, using the MKLINK command, started in Version 8.
--
HTH, Steve
| Steve Pitts wrote:
|| Anyone care to comment on whether or not there are advantages to
|| using symbolic links to a directory rather than junctions, or vice
|| versa??
|
| AFAIK, a Windows junction *is* a symlink, and has been available since
| Win2K. What *hasn't* been available is a tool to create them, unless
| you buy the Win2K Resource Kit.
Technically, a junction is not a symlink. Junctions are restricted to a single volume, symlinks can cross volume boundaries. Junctions can only reference a directory, symlinks can reference either a file or a directory. From a user's view there is no difference between a junction and a symlink, and I seriously doubt any performance difference. However, it appears that symlinks are preferred, as implied by the report of the ATTRIB command, which uses the letter L to report that a directory entry is either a junction or a symlink.
Ever since the release of Version 5 of 4NT users of JP Software command processors had the MKLNK command to create and delete junctions, and symlink support, using the MKLINK command, started in Version 8.
--
HTH, Steve
I've been creating them with 4NT for so long that I couldn't tell you when I started doing so :) and therefore I've never had any need for the Sysinternals tools that do so despite using a number of those tools for other things (4NT/TC has been the first software install on the last dozen new Windows installations I've done for myself, with the Sysinternals Suite about fourth or fifth). Sadly that MS page isn't really up to date and I've not been able to find anything from them that fully documents the differences, hence the question here.
My suspicion is that Windows 7 (at least) removes that restriction because I have Junctions on my C partition that point to the D partition, and the two are on separate disk devices.
In my experience Windows 7 and Vista installs both create directory structures containing broken Junctions (at least ones that I cannot follow using Explorer or a DIR command) and I have a batch file that finds and fixes those because it bugged me not being able to use the old-style directory references when there were links that looked like they ought to work.
From: Steve Pitts
| Originally Posted by Steve Fabian
|| Junctions are restricted to a single volume, symlinks can cross
|| volume boundaries
|
| My suspicion is that Windows 7 (at least) removes that restriction
| because I have Junctions on my C partition that point to the D
| partition, and the two are on separate disk devices.
Junctions and symbolic links are slightly different technologies used in NTFS to implement essentially the same concept. MKLNK always creates a junction if the target is a directory. MKLINK /J creates a junction, MKLINK /D a symbolic link. If you have been using MKLINK on Vista or later, you may have been creating symbolic links all along.
| In my experience Windows 7 and Vista installs both create directory
| structures containing broken Junctions (at least ones that I cannot
| follow using Explorer or a DIR command) and I have a batch file that
| finds and fixes those because it bugged me not being able to use the
| old-style directory references when there were links that looked like
| they ought to work.
All file systems which handle symbolic links can have broken links. "Shortcuts" (.LNK files) are also symbolic links when they just reference a directory entry. Directory structures do no have a field in which the number of symbolic links can be recorded (cf. the field containing the count of hard links, retrievable in 4NT/TCC using @LINKS[]). When a new symbolic link is created, the target must exist, but if the target is subsequently removed, the OS does not perform a search of the whole file system (think of a network) to find all symbolic links - the performace hit would be horrendous! This is no different from removing a book from a local library shelf and not updating the catalog of other libraries which have catalogs of the local library.
Any time you have references to an object in a system, removing the object itself makes all references invalid. To keep the whole system consistent at all times is possible only with great effort, typically not worth the effort. Consider what effort would be required when removing a terabyte drive from a USB port!
--
HTH, Steve
| Originally Posted by Steve Fabian
|| Junctions are restricted to a single volume, symlinks can cross
|| volume boundaries
|
| My suspicion is that Windows 7 (at least) removes that restriction
| because I have Junctions on my C partition that point to the D
| partition, and the two are on separate disk devices.
Junctions and symbolic links are slightly different technologies used in NTFS to implement essentially the same concept. MKLNK always creates a junction if the target is a directory. MKLINK /J creates a junction, MKLINK /D a symbolic link. If you have been using MKLINK on Vista or later, you may have been creating symbolic links all along.
| In my experience Windows 7 and Vista installs both create directory
| structures containing broken Junctions (at least ones that I cannot
| follow using Explorer or a DIR command) and I have a batch file that
| finds and fixes those because it bugged me not being able to use the
| old-style directory references when there were links that looked like
| they ought to work.
All file systems which handle symbolic links can have broken links. "Shortcuts" (.LNK files) are also symbolic links when they just reference a directory entry. Directory structures do no have a field in which the number of symbolic links can be recorded (cf. the field containing the count of hard links, retrievable in 4NT/TCC using @LINKS[]). When a new symbolic link is created, the target must exist, but if the target is subsequently removed, the OS does not perform a search of the whole file system (think of a network) to find all symbolic links - the performace hit would be horrendous! This is no different from removing a book from a local library shelf and not updating the catalog of other libraries which have catalogs of the local library.
Any time you have references to an object in a system, removing the object itself makes all references invalid. To keep the whole system consistent at all times is possible only with great effort, typically not worth the effort. Consider what effort would be required when removing a terabyte drive from a USB port!
--
HTH, Steve
Nah, my batch file explicitly uses MKLINK /J (see my post in the thread linked to below).
Sure, but MS breaks these ones (via their ACLs) deliberately, as per Vince's thread here:
OT:Explain Win7's "start menu" folder?
