Slashdot Mirror
Vista To Get Symlinks?
TheRealSlimShady writes "According to a post by Ward Ralston on the Windows server team's weblog, Vista server is to get symlinks as part of the SMB2 protocol." From the post: "In Vista/Longhorn server, the file system (NTFS) will start supporting a new filesystem object (examples of existing filesystem objects are files, folders etc.). This new object is a symbolic link. Think of a symbolic link as a pointer to another file system object (it can be a file, folder, shortcut or another symbolic link)."
...is a compliment of the highest form.
innovation from MS.
What a fantastic idea! Why didn't you UNIX guys think of that whilst you were eating ambrosia up in your ivory tower eh? ... Oh...
Microsoft 'innovating' once again, and giving the people what the want (10 years after everyone else). Go Redmond!
Scared of flying, pointy things snce 1979!
Welcome to the 1980s, Microsoft.
(Who was it who said: 'Those who don't know UNIX are condemned to recreate it. Badly.' ?)
The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
This is a joke, right?
Norman Cook's Ode to Sl
Those who don't understand UNIX are doomed to reinvent it, poorly." --Henry Spencer
Although the moon is smaller than the earth, it is farther away.
Some of the Vista previews have shown off things dubbed "virtual folders" which work in a similar way to browsing by artist or album in the current version of Media Player. You can manipulate the files like it's a normal folder window, yet the actual files may be scattered over different folders and drives. Presumably it's an effort to make managing large amounts of music/video outside of Media Player easier. They almost certainly use these symbolic links. They're a bit different from shortcuts.
No kidding!!! What do you say at this point?
From TFA:
"Now why is this relevant to the SMB2 protocol? This is because, for symbolic links to behave correctly, they should be interpreted on the client side of a file sharing protocol (otherwise this can lead to security holes). "
Is it not rather:
"If the client does not interpret symbolic links then nothing will work?"
See here :
m l
;-)
:(
http://www.sysinternals.com/Utilities/Junction.ht
Any feature new in Vista but the look and feel ?
What about booting the OS with less than about 20 services started and 256MB of memory used ?
Shortcuts are just ordinary files that, when opened, open the location it points to. A symlink, however, allows you transparently access it as though it were the actual file/folder; "C:\Shortcut to porn\hot lesbian action.jpg" won't work, whereas "C:\Symlink to porn\hot lesbian action.jpg" will. See the Wikipedia entry, for more info.
Perhaps you should of read the article, especially the bit "how is this different from a shortcut?"
The basis of it is that a shortcut is just a file - the exact same thing as a shortcut can be achieved by having a file with the target path just written in ascii inside, and assuming that the reader can tell it's a shortcut then it could get the target path sure, but if the reader is not equiped to specifically handle those shortcuts then it'll get muck.
A symlink masquerades as the actual file or folder, and the app doesn't need any specific handling to read the file. You can for example go into bash and write "cd symlink/" and it'll go to that folder. A shortcut is just a file, a symlink is an attribute of the filesystem.
Symbolic Link and SMB2 - should I also be waiting for ZeldaFS and MegaMon?
the date to see if it was April 1st.
They are just not accesible from the shell. You need 3rd party utils to use them.. http://www.sysinternals.com/Utilities/Junction.htm l
Vista - 1980's technology today^H^H^H^H^Hsometime next year.
Sean Ellis
Follow OfQuack's antics on Twitter.
that in about 2 years time, everybody will be running around saying that MS developed it, and that *nix copied it. Just the way it works.
I prefer the "u" in honour as it seems to be missing these days.
Now that NTFS has UNIX filesystem semantics, when will UNIX/Linux filesystems get some NTFS features like multiple streams and reparse points.
These features are incredibly useful (arguably more so than symlinks), and the only Linux fs that comes close to implementing them is reiser4, which is not even part of the kernel.
The inventors of Unix scrapped symlinks when they did their next OS
Symbolic links make the Unix file system non-hierarchical, resulting in multiple valid path names for a given file. This ambiguity is a source of confusion, especially since some shells work overtime to present a consistent view from programs such as pwd, while other programs and the kernel itself do nothing about the problem.
http://plan9.bell-labs.com/sys/doc/lexnames.html
NT *was* going to have executables that pretended to be files, i.e. when you opened the executable to get the contents it would run and return the output rather than the by bytes of the executable, with a special NT syscall to read the *real* contents. Kind of like a named pipe. I was looking forward to this but it didn't work out.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
My understanding is that NTFS does not use hard links (and the associated counts). If they are allowing symblics, why not allow hard links?
I prefer the "u" in honour as it seems to be missing these days.
We are the leaders, wait for us!
The Unix guys finally figure out how to move past symlinks to something better (private per-process inherited namespaces and bind() overlay mounts ala Plan 9 - coming to a Linux box near you soon), and now Windows starts implementing it for the first time (well
11*43+456^2
In Windows Explorer, the topmost level is the desktop, while in the CLI, there's as many 'topmost' levels as there are drives in the machine.
I never thought I'd say this, but I think they should adopt a *nix-like heirarchy, so that anything can be 'mounted' anywhere. Of course, they'd have to change the structure significantly, and have a built-in translator for "C:\things\stuff" type commands and whatnot.
But then, it'd probably be so hard to change all that, that they'd be better off doing an Apple OSX trick, and we all know how likely that would be...
When shortcuts were invented for Win95 the Win32 API should have been built to treat a shortcut as the object it pointed to. That way they would have had real working links up front. Now they are going to be stuck with two types of link which work in different ways.
http://michaelsmith.id.au
"Those who do not understand UNIX are doomed to buy Windows." --Anonymous Coward
When i create links in CYGWIN on my win32/NTFS box they appear in MS explorer as shortcuts and work like MS shortcuts but they act like symlinks, this lead me to belive that symlinks were possible under ntfs but not exposed to the user.
oops, isnt there still:
Make that FIVE ways. All of them looking somewhat alike, but all with subtly different syntax, semantics, overhead, and security implications. Sweet!
does the average user *really* need them? I certainly can't remember ever having said 'Damn, I wish this piece-of-crap-OS would support symlinks' during my Windows days.
Man, you need to use symlinks to see how useful they are. As someone pointed before, symlinks are great to create compilations of files on a directory. Also, they are very useful if you want to use different types of libraries (DLLs) on different programs (in different directoires).
As for the "average user", as someone else said also, this symlink will surely help the file system Virtual folders or whatever is named. It is the same as the SQL oriented file system, you could ask, will the average user make use of SQL queries?, and the answer is that, they will, indirectley through the applications that are make use of that technology.
Remember, this symlink will be a feature of the FILESYSTEM, which will be used by the programs. I for one would preffer to have multiple symlinks to DLLS than to have to copy the libraries through all the hard disk (or maybe not DLLS but other files).
Ubuntu is an African word meaning 'I can't configure Debian'
Bullshit. Most unix software is not aware of symlinks because it doesn't have to be. Generally, only system utilities care about the existance of symlinks. The OS will detect an attempt to open an infinitely recursive symlink.
There can be some improvement, particularly with managing symlinks.
/usr/tunes to /usr/local/tunes. Later, you symlink /usr/local/tunes/YMCA.mp3 => ~/my_favorite_song.mp3. Now, you have a symlink that relies on both the existence of "/usr/tunes/" AND symlink "/usr/local/tunes >> /usr/tunes". Thus, while deleting 1st ("/usr/local/tunes => /usr/tunes") symlink doesn't actually delete anything, it does cause ~/my_favorite_song.mp3 to become unworkable.
1) When you move a destination object, symlinks don't follow the target . This leaves "broken" symlinks that refer to nothing. Why doesn't the mv command move these too?
2) When you symlink a symlinked folder, the root symlink is ignored. Let's say you symlink
3) Symlinks cause all kinds of weirds around chrooted file systems , especially ones on a different underlying filesystem. If you're not very careful, nothing is as it seems! Files go nowhere, files are accessable only sometimes, etc. It's logical when you understand and appreciate a symlink for what it is, just a referral, but it can be maddening when security contexts get distorted around a chroot...
I have no problem with your religion until you decide it's reason to deprive others of the truth.
...is a compliment of the highest form.
Microsoft brought this on themselves by running around calling themselves "innovative" pretty much several times per sentence during the anti-trust trial, and then continuing with an ongoing PR campaign that still today tries to paint them as being a truly "innovative" company. If you go call yourself innovative, and then proceed to produce a new "modern" operating system for 2006/7 whose primary advancements are all features that were commonplace in many other products anywhere from five up to nearly thirty years ago, you are asking to be lambasted, and you are going to be. You claim to be something that strongly, then you better be able to properly back up that claim or people will call you out on it.
It's kind of like what Google did to themselves with their "do no evil" 'motto'. By having such a motto, they've created a whole crowd of people (and a whole sub-genre of "journalism") which specifically look for evidence that they are 'evil'.
>Any de1cent OS will detect an attempt to infinitely traverse a symlink, but what's it
>supposed to do?
>It can:
>
> * Close the program (= Possible data loss)
> * Slow the speed at which the program is allowed to access certain files (= Increase
>the chance of race conditions, sometimes by a lot. It doesn't really solve anything
>either)
> * Make the symlinks "disappear" after a certain level of recursion (= Inconsistent data)
> * Do nothing (= Solves nothing)
WTF.....
The answer is "none of the above". The open() call returns -1 with an error code of EMLINK, which if the program is any good will be passed onto the user as "Error opening file: Too many links", for the user to do with as he pleases.
>None of these options are as good as the software actually detecting the symlinks itself.
>When I say "most" UNIX software checks for symlinks, I am only referring to software
>which would otherwise be at risk of infinite recursion.
And what pray tell is the software supposed to do if it detects a symlink and/or a recursive one with special symlink handling code? All it can do is do report it to the user right? So why put in special code to do that? Just checking the return of open() and reporting the code to the user does the exact same thing.
I recall this Slashdot story from several years ago (damn, I can't believe a Slashdot headline has stayed with me that long). Sadly, the links referenced in the article are broken, so I don't recall exactly what it was about.
Bullshit. Most unix software is not aware of symlinks because it doesn't have to be. Generally, only system utilities care about the existance of symlinks.
/tmp, which can be exploited by planting symlinks at the right time.
I wonder if this attitude leads to all those race conditions when creating files in
The only way to really improve on symlinks is to get rid of file systems, and use a database instead. Symlinks are useful for simulating database views anyway.
The purpose of using a computer is to manage information, and not binary data. Files are relics of the past. Operating systems should have databases for managing persistence. Benefits whould be tremendous:
MS have invented symbolic links before.1 1&tid=109
http://slashdot.org/article.pl?sid=00/03/02/08332
The evidence is no longer on MS's website put you can find it here http://www.spinnwebe.com/contests/innovate/8.php
Reparse points (like links) http://msdn.microsoft.com/library/default.asp?url
Junctions (to mount file systems) http://msdn.microsoft.com/library/default.asp?url
Sparse files (highly underutilized) http://msdn.microsoft.com/library/default.asp?url
and of course the plain old short cuts that are really symbolic links in the traditional unix world.
I remember architecting a product to implement all unix based functionality in NT (IPC, memory mapped files, etc) and found NT40 to have that and more. Thats the time I really appreciated windows as a OS more mature than Unix.
The unfortunate part is people still think of DOS/Win95 code base when they think of windows. As a OS, W2K is much more mature in terms of the facilities they offer and as a filesystem, NTFS is way ahead.
Give me a feature in Unix and Im sure there is an equivalent in NT. Thousands of smart people working at Redmond are not idiots and millions of corporate architects proposing NT based solutions are not stupid either. They propose windows based technologies not just for looks (though end users do appreciate that).
That the Research Unix guys didn't add it to Plan9 doesn't have to mean anything else than they suffer from the NIH syndrome. I don't believe symbolic links were ever a part of Research Unix.
The commercial product, SysV, got symbolic links, but they had to compete in the real world.
Yes, the Mac OS had none of those problems with Aliases. I guess that's what happens when you design an OS from the ground up that doesn't use paths to reference everything. In fact, for a very long time there was no way to get a path in the Mac OS. OS X changed all that and now many programs are very fragile (like Preview).
Well. So does FAT, except it is called a crosslink, and aparently scandisk and various disk defragmentation tools do not handle it correctly ;-)
I know the UNIX security record relating to symlinks is not unblemished.
I can't help but be curious - Will this be a new avenue by which to exploit Windows systems? I'm not saying this to troll, or to jump on the "MS security sux fanboi wagon" but rather as a concern.
This new development has definitely piqued my interest.
First Microsoft Shell and now this? Looks like MS Linux is nearly becoming a reality!
It seems people are forgetting about the "almost there" aspects of NTFS 5 ..
.. Distributed Link Tracking and Object Identifiers ... http://support.microsoft.com/default.aspx?scid=kb; EN-US;q205524
NTFS junction points are useful for alternate mounting.
The point of some key Windows Services are built for exactly this purpose
Reparse points are handy too
NTFS is a great file system, you just need to read the documentation..
The whole point of symbolic links is that they're transparent. That way, an application doesn't have to parse a .lnk file. The OS handles reading/writing from the correct file. Real file symlinks have been missing from Windows for too long, I think it's about time they were added. (Whether or not anybody actually uses them instead of shortcuts is another story.)
I try and keep them relevant.
This story is a case in point. Symlinks are a hack that hides the fact that disk drive based namespaces are a crock. And a crock that's easily solved.
Unix is 30 years old, Linux copies it. Windows is not in the picture.
Linux / BSD et. al. offers very little innovation any more. Instead anything new is coming in through the user space and we end up with stuff like GnomeVFS and smb:// handlers.
The only real place where any real Unix like innovation has occured in recent times was in Bell Labs and the expresssions of that are Plan 9 and Inferno.
You can try some of the concepts out in user space through http://swtch.com/plan9port/
"Plan 9 from User Space (aka plan9port) is a port of many Plan 9 programs from their native Plan 9 environment to Unix-like operating systems.
supported systems : Linux (x86 and PowerPC), FreeBSD (x86), Mac OS X (Power PC), NetBSD (x86), OpenBSD (x86 and PowerPC), SunOS (Sparc)."
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
This is just one more clue that Microsoft has given up on the Windows code base, and that Vista will be based on BSD code.
.Net to BSD, as well as pushing for other software to be released under a BSD license ("All the better to steal it, my dear.").
.Net, were all based on other companies' products, or were developed by teams hired from outside.
To review the previous clues:
First, there was Microsoft's announcement that Vista (Longhorn) will use UNIX-like User Permissions:
See Longhorn to use UNIX-like User Permissions
Why would Microsoft do that, when even many Linux supporters agree that Windows permissions are finer grained? But if the new Windows is BSD-based, Microsoft would be forced to do that, or face rewriting a lot of the underlying BSD code.
Second, there was Microsoft's announcement that Unix compatibility will be "built in" to Vista:
See: Microsoft to Stop Releasing Services for Unix
Third, there is the fact that Microsoft ported
Fourth, there was Steve Ballmer talking about the Vista "reset" which started around 18 months ago.
See: Ballmer Pushes Microsoft Innovation, Talks Vista Reset
Does anyone really think that Microsoft could succeed in doing a major rearchitecturing of the Windows code now, in only 18 months, after they had tried and failed to do so many times over the last decade?
Besides, when has Microsoft ever shown the confidence or ability to succeed on their own? DOS, Windows NT, Internet Explorer, and
And now we have this new report that another basic feature of Unix, symbolic links, will be part of Vista.
Given all this evidence, I am fairly convinced that Vista will be based on one of the Open Source BSD distributions. Unlike Apple, however, Microsoft will probably try to keep it a secret, and claim it as their own innovation.
What will be the result?
On one hand, a BSD-based Vista might be a good thing, since it will result in a more stable, and less virus-prone Windows.
On the other hand, if Microsoft remains true to their history, they'll just screw it up with all the lock-in features they'll add on top. Like the VMS-and-OS/2-based Windows NT, which started out strong (version 3.51) then gradually degraded, I expect the benefits of a BSD-based Vista to be temporary.
Then again, Microsoft is just playing for time, as they continue their strategy of locking in the Internet. Thus, they only need Windows to be better for long eneough to fool their customers, again, while they tie them up with a new set of decommoditized protocols (.Net, Palladium, DRM, Windows Media, Office 12, and so on).
Yes, you could essentially re-implement Explorer in every app written by having them handle the *.lnk files the way Explorer does. It sort of is counterproductive. It is much cleaner to have that in the filesystem (or at least the MS APIs to open files) so that it is transparent to apps. Frankly the way the shortcut thing was implemented is a ugly hack. I figured what happened is that they wanted the symlink concept, but didn't want to (or couldn't) change the filesystem. Looks like they're finally (10 years later) decided to do it right.
As far as users are concerned, I suspect they won't know/see the difference. Creating symlinks will just work like creating shortcuts.
NAME SYNOPSIS DESCRIPTION RETURN VALUE
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
I hate how Mac OS X handles symlinks. Symlinks work perfectly, both within the shell and within the Finder, but the Finder doesn't create symlinks... it creates Aliases (think "Shortcuts").
.lnk file in Windows.
"Aliases" don't work in the shell. They're files. Trying to "cd" to one of them is like trying to "cd" to a
I wish the Finder created symlinks (or, at least, that you can make it do so) instead of Aliases.
And I hope that, if and when Windows starts to support symlinks, explorer.exe will create symlinks instead of Shortcuts.
With spending like this, exactly what are "conservatives" conserving?
Later on, Vista wakes up. He sees his code-base pierced with dozens of acupuncture-like needles wired to a strange device insert new lines of source code.
*nix Developer 1: He still needs a lot of work.
Vista: What are you doing?
*nix Developer 2: Your source code has atrophied, we're rebuilding them.
Vista: Why do the symbolic links in my file system hurt?
Vista blinks
*nix Developer 2 : You've never used them before.
Vista looks confused
*nix Developer 2 : Rest, Vista, the answers are coming.
Vista passes out again.
Why did I lurk so long before registering for a Slashdot account? I could have had a Slashdot ID of less than 100000.
Mac OS X (and all the way back to System 7 in 1990) did it right by creating aliases which use a two-factor plan to locate its target:
Aliases also store sufficient information about the volume they were located on that the Finder can mount the volume automatically (if it's on the network) or inform the user of exactly why it didn't work. This also allows aliases to cross filesystems, which symlinks can but hard links cannot.
This is why symlinks are such a stupid solution on UNIX, since that OS has no excuse - aliases could have been trivially implemented due to the dual-layer nature of the filesystem (inodes separate from hierarchy).
(Now, I agree completely with how sucky it is that the shell does not support them, and that aspect has been sucky since day 1. However, that has nothing to do with alias technology and everything to do with shell implementation.)
I don't know what kind of crack I was on, but I suspect it was decaf.
NTFS has had hard links since the first version in 1993. Reparse points were added to NTFS in Windows 2000. These work like symbolic links, but can only point at directories, not files.
FAT filesystems have had hard links since the beginning, but CHKDSK doesn't like 'em... :-)
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
Are Plan 9 users the new Ubuntu users (who were previously the new Gentoo users)? ;)
Sorry, but that dog don't hunt this time. It's trivial to write a filesystem driver to create a virtual drive letter for legacy applications that would need such while at the same time making useful things available like true loing filenames, symbolic links, etc.
That's the same excuse that they used for using FAT32 in Win9x, but OS/2 proved them wrong even before the first Win9x release when OS/2 2.0 allowed DOS and Windows programs to install and run on an HPFS partition. Even Windows 3.1 itself could be installed under OS/2 on HPFS!
Besides, I think
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.