Linked by Thom Holwerda on Sat 18th Nov 2006 23:26 UTC, submitted by Dolphin
Windows "It's not often that something we classify as a 'really good' feature turns out to be a bit of a sham, but unfortunately, that's the case with Vista's symlinks. Just a couple of days ago, symlinks were our 'big Vista feature of the week', but now, we're not so sure."
Order by: Score:
Author is clueless
by Tom K on Sun 19th Nov 2006 00:04 UTC
Tom K
Member since:
2005-07-06

The author is clueless. Read the following:

"If your buddy at work has the latest documents for the project you’re both co-working on in his shared documents folder symlink’d over to the actual path (so he doesn’t have to manually synchronize the directories nor remember to keep changing permissions on shares), you can’t get it from your XP workstation."

NO symlink implementation works that way. Symlinks are relative/absolute to the local drive. If there is a symlink pointing to /home/tom/project.doc in a shared directory on the network, and Bob over in Accounting wants to take a look at it, when he opens the symlink, HIS LOCAL SYSTEM will try to read "/home/tom/project.doc" -- which of course doesn't exist.

Author needs to learn what symlinks actually are.

Reply Score: 1

RE: Author is clueless
by smitty_one_each on Sun 19th Nov 2006 00:12 UTC in reply to "Author is clueless"
smitty_one_each Member since:
2005-07-07

Your assertion may hold true.
However:
They’re not a part of the (allegedly) revised NTFS filesystem, and as far as we can tell, they’re not well-incorporate into the kernel either.
How is it that a feature that is clear, simple, and obvious in *nix has to be a challenge for Redmond?
Is there some patent challenge rationale for not just implementing the file equivalent of a pointer? WTF, K.

Reply Score: 3

RE[2]: Author is clueless
by n4cer on Sun 19th Nov 2006 05:42 UTC in reply to "RE: Author is clueless"
n4cer Member since:
2005-07-06

They’re not a part of the (allegedly) revised NTFS filesystem, and as far as we can tell, they’re not well-incorporate into the kernel either.

As the first poster said, the article's author is simply clueless. There's nothing alleged about the file system modifications. It's the reason why symlinks can't be evaluated on older versions of Windows.

A couple of minutes of searching would've given him information about symlink evaluatetion and their default behavior on Windows.

Q: So then, what is the difference between a shortcut and the links?
A: A shortcut is a file implemented by Shell32 via the IShellLink interface. These files tell shell to jump to a different location. A symbolic link is implemented under the filesystem API, so regular applications calling CreateFile get the benefit of links without needing to implement their own code, as they would with IShellLink.

Q: What is the difference between a junction point, and a directory symlink?
A: Junctions and directory symlinks have subtly different semantics. For example, symbolic links are always evaluated on the client in a network scenario, whereas junctions are evaluated on the server. Also, ACLs are handled differently too. However, they are broadly similar.

Q: Should I be able to access a symlinked folder via the network?
A: Yes, remember that the client and the server needs to be Vista. By default only local to local links are turned on. You would need to enable the Local to Remote symlinks through the policy editor.
https://blogs.technet.com/filecab/articles/457811.aspx

Checking the Group Policy Editor in Vista (gpedit.msc) as advised above yields the following option under Computer Configuration | Administrative Templates | System | NTFS File System:

Selectively allow the evaluation of a symbolic link
o Not Configured (Default)
o Enabled
o Disabled

[] Local Link to Local Target
[] Local Link to a Remote Target
[] Remote Link to a Remote Target
[] Remote Link to a Local Target

Explaination:
Symbolic links can introduce vulnerabilities in certain applications. To mitigate this issue, you can selectively enable or disable the evaluation of these types of symbolic links:

Local Link to a Local Target
Local Link to a Remote Target
Remote Link to Remote Target
Remote Link to Local Target

For further information please refer to the Windows Help section

NOTE: If this policy is Disabled or Not Configured, local administrators may select the types of symbolic links to be evaluated.

Reply Score: 5

RE[3]: Author is clueless
by Dolphin on Sun 19th Nov 2006 09:52 UTC in reply to "RE[2]: Author is clueless"
Dolphin Member since:
2006-05-01

I'll refer you to this comment made on the article with regards to your reply (or so it would seem):
http://neosmart.net/blog/archives/285#comment-7468

Reply Score: 3

RE[4]: Author is clueless
by n4cer on Sun 19th Nov 2006 16:10 UTC in reply to "RE[3]: Author is clueless"
n4cer Member since:
2005-07-06

I'll refer you to this comment made on the article with regards to your reply (or so it would seem):
http://neosmart.net/blog/archives/285#comment-7468


From the comment:
The GPE enables symlinking on NFS for Vista clients only and does nothing to address the main issue here; which is that Vista doesn’t support symlinks on NFS for anything other than another Vista machine. Users of older Windows and other platforms will not be able to access Symlinks on network shares regardless of what settings you picked in the GPE.

1) Is he actually using NFS or is he just using that as a general term? He should test the n*x client scenario with Windows Server "Longhorn" as NFS Server functionality is limited on clinet versions of Windows. If that scenario does not work, it's likely a protocol issue, i.e. MS needs to add support for the new symlinks to their NFS implementation.

2) If he's just using NFS as a general term and is really trying symlink interop using older versions of Windows or something like samba that either only supports SMB 1.0, or does not support symlinks in SMB 2.0, he will not be able to interop symlinks to anything other than Vista or Windows Server "Longhorn". SMB 2.0 is a modern redisign of SMB that's new in Vista. Samba 4 only has experimental support for it currently, and I'm not sure if that includes support for symlinks.

Reply Score: 2

RE: Author is clueless
by tscholz on Sun 19th Nov 2006 00:32 UTC in reply to "Author is clueless"
tscholz Member since:
2005-07-08

Symlinks (on unix atleast) works at filesystem level, and are parsed by system calls. And since a "file share" is usually done through a daemon like samba or apache. The daemon uses system calls to read files, and can access symlinks just fine. The application can choose to ignore symlinks, which apache does with an option. But if the application is ignorant of the concept of symlinks, it will not know the difference between the symlinks and the real file.

What you describe would be true with something like the shortcut feature in Windows.

Reply Score: 5

RE[2]: Author is clueless
by rayiner on Sun 19th Nov 2006 00:59 UTC in reply to "RE: Author is clueless"
rayiner Member since:
2005-07-06

No, he's right. Symlinks are usually just a file containing the path of the real file (or that data stuffed into the inode or something along those lines). They are always interpreted relative to the local namespace. The only way that scheme would work is if the real path of the work directory happened to be the same on both machines. If the shared folder was /home/rayiner on one machine, and /mnt/rayiners-machine/home/rayiner on the other, the symlink wouldn't work.

Reply Score: 1

RE[3]: Author is clueless
by wirespot on Sun 19th Nov 2006 01:05 UTC in reply to "RE[2]: Author is clueless"
wirespot Member since:
2006-06-21

People, what are you smoking? There's no bloody way you're going to get a symlink on a remote filesystem refer to an actual file on your local filesystem! It's been said above, I'll say it again: to the one accessing remotely, symlinks look just like real files. The daemon serving the files (Samba, Apache) will translate them on the fly.

Reply Score: 5

RE[4]: Author is clueless
by kokara4a on Sun 19th Nov 2006 18:45 UTC in reply to "RE[3]: Author is clueless"
kokara4a Member since:
2005-09-16

Well, NFS seems to be an exception. A symbolic link on a remote share is treated as local to where it is mounted from. It has to be like that otherwise you will not be able to create symbolic links on a remote filesystem. I guess other networked filesystems of Unix breed will do the same.

Reply Score: 1

RE[3]: Author is clueless
by tscholz on Sun 19th Nov 2006 01:16 UTC in reply to "RE[2]: Author is clueless"
tscholz Member since:
2005-07-08

While it's true that it is just a file that points to the real file, it's all about who interprets it. If it has to be done by the application that opens it (like windows shortcut), or by the kernel/filesystem. On most unix platform, if i'm not mistaken, symlinks are done by kernel/filesystem. So the application does not have to know that it's opening an symlink.

Reply Score: 4

RE: Author is clueless
by fsckit on Sun 19th Nov 2006 03:06 UTC in reply to "Author is clueless"
fsckit Member since:
2006-09-24


NO symlink implementation works that way.



Alright smart guy.

This is an nfs share

jamesb@odin:~$ df -h
Filesystem Size Used Avail Use% Mounted on
thor:/home/jamesb/share
254G 139G 102G 58% /fileserv

This is a symlink working just fine over a network mount.

jamesb@odin:~$ ls -l /fileserv/asymlink
lrwxrwxrwx 1 jamesb jamesb 10 2006-11-18 22:03 /fileserv/asymlink -> backup.tgz

Any questions?

Reply Score: 5

RE[2]: Author is clueless
by squainter on Mon 20th Nov 2006 18:22 UTC in reply to "RE: Author is clueless"
squainter Member since:
2005-07-07

Actually, this synlink could work because the file it points to is relative to the link. So, if you mount this on a remote client, the target will still be relative to the mount point, regardless of the mount point itself. However, if you pointed your link to a file in another part of the filesystem, the link will fail, because, as was pointed out before, the client interprets the link path depending on what the server reports. So, if the server says that the file foo.txt points to another file called /etc/sfw/bar.txt, then that path needs to reside on your client (which of course you could NFS mount to the client as well). The nice thing about Unix symlinks, which are the only sort I've ever worked with, is that they are brain-dead simple. They are only inodes containing the path to the target file, which is then opened once the system realizes the first file was a link. Simple. And the nice thing about NFS is it simply presents directory contents to the client as if they were local. No magic. If the file's there and you have permissions to open it, you can open it. If it's not there, or you have no permission to do a read, you're out of luck. Who would expect anything else?

Reply Score: 1

RE: Author is clueless
by Archangel on Sun 19th Nov 2006 04:36 UTC in reply to "Author is clueless"
Archangel Member since:
2005-07-23

NO symlink implementation works that way. Symlinks are relative/absolute to the local drive. If there is a symlink pointing to /home/tom/project.doc in a shared directory on the network, and Bob over in Accounting wants to take a look at it, when he opens the symlink, HIS LOCAL SYSTEM will try to read "/home/tom/project.doc" -- which of course doesn't exist.
You're wrong. I just had a quick test of this, by creating a symlink /tmp/vt to /var/tmp. Sure enough, when browsing through Samba, I can happily follow that symlink and see the contents of my /var/tmp folder (on the server, _not_ on the client).

Obviously it is up to the network FS implementation how it handles symlinks, but I'd tend to think that on a Unix-type system they'd probably 'just work' as you expect, because they're being handled transparently by the filesystem - most operations on the link look exactly like there really is a directory there.

Whereas it seems Microsoft's done some dodgy hack to get them into Vista, but because of that it's not really universal. At this point, I can't even muster up any surprise at that.

Edited 2006-11-19 04:37

Reply Score: 5

RE: Author is clueless
by Dolphin on Sun 19th Nov 2006 05:00 UTC in reply to "Author is clueless"
Dolphin Member since:
2006-05-01

Author needs to learn what symlinks actually are.

I guess someone needs to learn to do a bit of quick research before commenting. I guess we know who "Anony" that commented immediately with offensive language on the article in question. People like you make me sick.

Test it for yourself and see what symlinks actually are, as you say. Do your research first, then put your money where your mouth is.

The sad thing is, you had a 5 rating for a completely BS reply that made no sense and was completely made-up. You obviously never read a thing about Symlinks, and didn't bother to test your "theory" out, yet quite a few people believed you and thought you were saying something that made sense. Yuck.

Reply Score: 5

v Its Out already
by Bajan on Sun 19th Nov 2006 00:13 UTC
questionable
by vicious1 on Sun 19th Nov 2006 00:31 UTC
vicious1
Member since:
2006-11-10

yea the article seems to be a little bit of a ... well.. ;)

But I am wondering really what Vista will turn out as after a while and once people (read: power users) are really using it and start finding the quirks.

I think once Vista Retail hits the market we will have some very interesting times ahead. I just hope not everyone on the planet will write a "Vista review". They should just have a central image server were all the "reviewers" can link to ;)

//FR
http://blog.2blocksaway.com

Reply Score: 1

NTFS Junction
by garapheane on Sun 19th Nov 2006 01:14 UTC
garapheane
Member since:
2006-01-04
IP steal
by eantoranz on Sun 19th Nov 2006 02:13 UTC
eantoranz
Member since:
2005-12-18

Sarcasm: These guys are obviously in danger because of unix IP infringement. I bet "cousin' stevie" doesn't know about it, or symlinks wouldn't have made it to Vista.

Edited 2006-11-19 02:21

Reply Score: 5

RE: IP steal
by CowMan on Sun 19th Nov 2006 14:34 UTC in reply to "IP steal"
CowMan Member since:
2006-09-26

You've got this all wrong. They're only implementing symlinks so they can sue the pants off anyone who uses them on a non-windows platform.

It's not like they are going to care how frivolous the suits are anyway ;)

Reply Score: 2

Further reading
by NotParker on Sun 19th Nov 2006 03:09 UTC
NotParker
Member since:
2006-06-01

http://schinagl.priv.at/nt/hardlinkshellext/hardlinkshellext.html#s...

"Symbolic Links are to files what Junctions are to folders in that they are both Transparent and Symbolic. Transparency means that an application can access them just as they would any other file, Symbolism means that the data objects can reside on any available volume, i.e. they are not limited to a single volume like HardLinks. Symbolic Links differ from Shortcuts in that they offer a Transparent pathway to the desired data object, with a shortcut (.lnk), something has to read and interpret the content of the shortcut file and then open the file that it references (i.e. it is a two step process). When an application uses a symlink it gains immediate access to the data object referenced by the symlink (i.e. it is a one step process)."


"The NTFS file system implemented in NT4, Windows 2000, Windows XP and Windows XP-64 supports a facility known as hard links (referred to herein as HardLinks). HardLinks provide the ability to keep a single copy of a file yet have it appear in multiple folders (directories). They can be created with the POSIX command ln included in the Windows Resource Kit or the fsutil command utility included in Windows XP. Thus, using standard Windows facilities HardLinks can only be created at the command prompt, which can be tedious, especially when HardLinks to multiple files are required or when one only makes occasional use of HardLinks. Support for Junctions in standard Microsoft software offerings is even more limited than that offered for HardLinks.

Link Shell Extension (LSE) provides for the creation of HardLinks , Junctions , and Vista's Symbolic Links, (herein referred to collectively as Links) and a Folder Cloning process that utilises HardLinks or Symbolic Links. LSE, as its name implies is implemented as a Shell extension and is accessed from Windows Explorer, or similar file/folder managers. The extension allows the user to select one or many files or folders, then using the mouse, complete the creation of the required Links - HardLinks, Junctions or Symbolic Links or in the case of folders to create Clones consisting of Hard or Symbolic Links. LSE is supported on all Windows versions that support NTFS version 5.0 or later, including Windows XP-64 and the upcoming Vista operating system. HardLinks, Junctions and Symbolic Links are NOT supported on FAT file systems, and nor is the Cloning process supported on FAT file systems."

Reply Score: 1

NTFS has symlinks too...
by jasutton on Sun 19th Nov 2006 03:46 UTC
jasutton
Member since:
2006-03-28

it wasn't really "supported" by MS, but it was there. There's a tool to create them out there too, although I've read it's more of an OS hack than anything.

Reply Score: 1

What no one has mentioned...
by StephenBeDoper on Sun 19th Nov 2006 07:08 UTC
StephenBeDoper
Member since:
2005-07-06

Yay, finally an file/directory linking mechanism for Windows that *should* actually work from the command line level. Aka, no more stupid .lnk files.

Reply Score: 2

Windows != Unix...
by Brendan on Sun 19th Nov 2006 07:49 UTC
Brendan
Member since:
2005-11-16

<joking>
Just because Windows symlinks don't work like Unix symlinks, doesn't necessarily mean they weren't meant to behave like they do in Vista. The real question is how long it will take before this new symlink behaviour is ported to Suse (inter-operability is important after all)...
</joking>

Reply Score: 3

Hope they will be labelled
by Havin_it on Sun 19th Nov 2006 10:39 UTC
Havin_it
Member since:
2006-03-10

I just hope Explorer will actually flag the symlinks/junctions/etc for what they are. I once inherited an XP system that was riddled with junction points, and it took a lot of confusion before I realised that's what was going down. At least in Konqueror I can see exactly what is a symlink, and where it points to, in the tooltip.

Reply Score: 3

RE: Hope they will be labelled
by n4cer on Sun 19th Nov 2006 16:31 UTC in reply to "Hope they will be labelled"
n4cer Member since:
2005-07-06

I just hope Explorer will actually flag the symlinks/junctions/etc for what they are. I once inherited an XP system that was riddled with junction points, and it took a lot of confusion before I realised that's what was going down. At least in Konqueror I can see exactly what is a symlink, and where it points to, in the tooltip.

Vista's Explorer shows links as shortcuts (i.e. the icon is overlaid with the little arrow). Theirs also a Link Target attribute you can enable that will give you the path to which the link points (if any).

Reply Score: 2

security??
by dmitry on Sun 19th Nov 2006 17:35 UTC
dmitry
Member since:
2006-01-16

Well, if Vista is able to follow the symlinks via network , it looks to me like a back door offered by MS itself...

Reply Score: 1

RE: security??
by n4cer on Sun 19th Nov 2006 20:29 UTC in reply to "security??"
n4cer Member since:
2005-07-06

By default, only Administrators are allowed to create symbolic links, and only local-to-local and local-to-remote links are allowed. So basically you're limited to shortcuts to local resources and file shares (which is similar to what you have in previous versions of Windows). If you link to a share that is linked to another share, you will not be able to traverse that link by default.

If you choose to trust a share, enable remote access, and/or to give users the ability to create symlinks, you should have some knowledge of the implications.

Reply Score: 3

Vista SymLinks
by malxau on Tue 21st Nov 2006 01:46 UTC
malxau
Member since:
2005-12-04

bio: I'm a regular osnews reader (though seldom make comments), and for the last little while I've been maintaining NTFS up here in Redmond.

The article describes accurately how symlinks work in Vista, although it should be pointed out that this is completely by design.

A junction is evaluated on the server. A symlink is evaluated on the client. At least as far as directories are concerned, Vista gives you the choice about which evaluation method you prefer. Unfortunately, there is no such thing as a file junction, so linking to files requires symbolic links.

As other comments point out, the reason the user scenario works on Linux is because Samba etc. evaluate the symbolic link on the server so that an NT4 Windows client can "traverse" the link because it never really traverses anything. Samba turns client-evaluation into server-evaluation, which works pretty well, at least most of the time.

Others here have commented that it's unwise to have a link on a remote share that links to a local file. That is correct, and by default, Vista has policies that prevent evaluation of those links. However, it is configurable - you can have these links if you really want to, unwise or not.

The design of symlinks was client-evaluation. Server-evaluation would have been a *lot* easier (and faster!) to do. This behavior will not change in a hotfix/qfe/service pack/fiji/anything else.

Also, to be clear, we've been very consistent about NTFS - the on-disk NTFS format has not changed. The on-disk format is 3.1, which is the same as XP. This is important for compatibility. Symlinks are just reparse points. You could, given enough free time and a Win2k IFS kit, build your own Vista-Symlink-evaluator for Win2k. Similarly, Samba could be made to parse them, although there would be namespace translation issues (what's C:foobar on Linux anyway?)

The real prick with Vista Symlinks is (as others have pointed out) the requirement that, by default, only admins can create them. There are several compatibility/security reasons for this, which belong in a seperate discussion. Hopefully *that* can be fixed in future - but it won't be until a future Windows release, at the earliest. You can change this behavior by giving other groups the right - mmc, local computer policy, computer configuration, windows settings, security settings, local policies, user rights assignment, create symbolic links.

Reply Score: 1