Vista To Get Symlinks? 565
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)."
Duplication... (Score:5, Insightful)
Re:Duplication... (Score:2, Funny)
Duplication... (Score:5, Funny)
Re:Duplication... (Score:3, Funny)
More Dupe than you think (Score:4, Informative)
Re:More Dupe than you think (Score:3, Informative)
is one place to start. [microsoft.com]
Still, it'll be very nice to have real symlinks instead of shortcuts. It's what the shortcuts should have been all along.
Yet more great (Score:5, Funny)
Re:Yet more great (Score:5, Funny)
Re:Yet more great (Score:3, Informative)
Five years to late [slashdot.org]
Re:Yet more great (Score:3, Funny)
Funny thing is... (Score:5, Insightful)
Re:Funny thing is... (Score:4, Funny)
Re:Funny thing is... (Score:4, Funny)
Dennis Thompson? I didn't know that Dennis Ritchie [bell-labs.com] and Ken Thompson [bell-labs.com] fused and merged together back in the 60s to become ... Dennis Thompson.
Re:Yet more great (Score:5, Funny)
Forward slashes?
Text files without ^m's?
Re:Yet more great (Score:3, Funny)
Now that would be demanding a little bit much in so short time, wouldn't it?
We will have to wait at least until the avarage workstation has 30GHz dualcore CPUs and at least 10GBs of ram.
Re:NTFS already had symlinks? (Score:4, Insightful)
Re:Yet more great (Score:5, Funny)
Vista Will Probably Be BSD-Based (Score:4, Interesting)
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 [slashdot.org]
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 [slashdot.org]
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 [windowsitpro.com]
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).
Re:Vista Will Probably Be BSD-Based (Score:3, Insightful)
So you have three reports on
From these three technologies, al
Re:Vista Will Probably Be BSD-Based (Score:3, Funny)
Re:Nevermind (Score:5, Insightful)
Re:Nevermind (Score:4, Informative)
As far as users are concerned, I suspect they won't know/see the difference. Creating symlinks will just work like creating shortcuts.
Symbolic links? (Score:3, Funny)
Microsoft 'innovating' once again, and giving the people what the want (10 years after everyone else). Go Redmond!
Re:Symbolic links? (Score:5, Insightful)
It's not like Linux never copied an idea from another OS, yet it seems MS is not allowed to add a feature unless they thought of it themselves.
But then I guess everyone here gets a bit bitter when there is one less thing to complain about MS.
Re:Symbolic links? (Score:5, Informative)
Also, FAT had initially a flag indicating that an object is not a file, nor a folder, but a symlink. Unfortunately, the attribute got later used as a "Long Filename Part no. X" flag... talk about bad design..
Re:Symbolic links? (Score:3, Informative)
There is a huge difference between the two: a hard link is filesystem-level (simply a second entry in a directory to a file); a symlink is OS-level. One cannot cross filesystem boundaries (being filesystem-level), the other can.
Re:Symbolic links? (Score:4, Informative)
Windows 2k and above have both hardlinks (which are available via standard tools) as well as symlinks, restricted to directories only and not available via the OS' tools.
Check Juctions [sysinternals.com] for the creation and handling of symlinks.
Re:Symbolic links? (Score:3, Informative)
That would be really funny if it was true.
It is, alas, false, and junctions do not become "a drive letter", they are virtual folders akin to Linux' directory symlinks (since junctions sadly don't handle the file level but only the directory one).
Re:Symbolic links? (Score:4, Informative)
Re:Symbolic links? (Score:3, Insightful)
Re:Symbolic links? (Score:3, Informative)
And, more "F.U.D." attempts by the 'pro-Unix/Linux/BSD' brothers @ "/.", as-per-usual... or, the usual "partially informed/incomplete data spouting rumor mill" is @ work here again, as-per-usual.
Take a read, so you are better informed:
http://www.sysinternals.com/Utilities/Junction.htm l [sysinternals.com]
-----
Win2K's version of NTFS supports directory symbolic links, where a directory serves as a symbolic link to another directory on the
Re:Symbolic links? (Score:3, Informative)
Actually, 95% of the world's computers are embedded microproccessors, most of which don't even run anything classified as an "operating system", let alone windows. I expect that what you meant was that 95% of PC's are running Windows NT based operating systems. I doubt that, there are still plenty of older, pre-XP home machines in use today, so probably as many as 15-20% of PC's are running Windows 9x-based operating systems. Yo
Allow me to be the first to say... (Score:5, Funny)
(Who was it who said: 'Those who don't know UNIX are condemned to recreate it. Badly.' ?)
Re:Allow me to be the first to say... (Score:4, Insightful)
Re:Allow me to be the first to say... (Score:5, Insightful)
Backward compatibility is absolutely indispensable for Microsoft - the only reason it's still the market leader after all the lawsuits, bad publicity and downright talented competition of the last few years is because nobody wants to break compatibility with their existing software, documents, networks and hardware. Microsoft understands this, and while I'm sure it drives a lot of MS developers insane, backward compatibility is always given top priority, even if it makes the architecture horribly ugly and illogical.
(If you want to see the Unix equivalent, read the chapter on terminal I/O in Stevens' Advanced Programming for the UNIX Environment. There are backward compatibility hacks in there that are so ugly you'll wish you'd been born blind.)
Ah, the "backwards comptibility" card... (Score:3, Insightful)
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
Re:Allow me to be the first to say... (Score:5, Informative)
$ fortune -m 'condemned'
...
Those who do not understand Unix are condemned to reinvent it, poorly. -- Henry Spencer
And those who don't understand fortune(1) are condemned to ask about quotes =)
OMG (Score:2, Funny)
Obligatory quote (Score:3, Funny)
It's worse (Score:3, Funny)
Different than shortcuts (Score:5, Informative)
Re:Different than shortcuts (Score:3, Insightful)
If you open the file up in XP, Word will be very confused, and if anything, display the 1000-byte gibberish. In Vista, Word (and Outlook, and everything else) will automatically do the right thing, and read the contents of MyDocument1.doc without having to change any code in Word/Outlook/etc.
Since it's aan automatic part of the operating system, all previou
Only on BSD and Linux... you want readlink. (Score:3, Informative)
NAME
SYNOPSIS
DESCRIPTION
"Virtual folders", I believe it's used for (Score:5, Informative)
Re:"Virtual folders", I believe it's used for (Score:5, Informative)
Security risk? (Score:5, Interesting)
"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?"
Re:Security risk? (Score:5, Interesting)
If the server did no special behaviour for symlinks then they would appear to the client as a duplicate of the symlink target, an ordinary file.
NTFS already does it since Win2K ! (Score:5, Informative)
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 ?
Re:NTFS already does it since Win2K ! (Score:3, Informative)
http://slashdot.org/article.pl?sid=00/03/02/08332
The links in the summary are broken though.
Re:NTFS already does it since Win2K ! (Score:3, Insightful)
I've been wishing Windows would support this elemental feature for a long time now. I would have used it to create a directory tree with the structure I wanted to burn on CD, without having to move all the actual files around. The CD burning software I've tried doesn't understand shortc
Re:NTFS already does it since Win2K ! (Score:3, Informative)
Re:NTFS already does it since Win2K ! (Score:3, Informative)
Soft links are represented as a special text file that contains the name of the linked file. The default behavior on opening a soft link is to redirect and open the target file ins
Re:NTFS already does it since Win2K ! (Score:5, Informative)
NTFS does support hardlinks and, as the developers of the NTFS driver for Linux recently discovered (see details in this thread [theaimsgroup.com]), it also supports symlinks, provided Microsoft Services For Unix are installed.
The important part of all this, is, I think, that open source tools ranging from the linux fs drivers (ntfs and cifs/smb) to the cygwin stuff should get updated and start managing the thing the way MS does it (on MS filesystems, of course).
Re:NTFS already does it since Win2K ! (Score:3, Insightful)
The pain (or feature) with junctions is the source directory doesn't have to be empty. As a System Administrator in the Managed Storage group this can be an incredible pain. If the destination points to another drive you don't want to include it in the backups since things will get backed up twice (since the os w
FAT does it too... (Score:5, Funny)
Well. So does FAT, except it is called a crosslink, and aparently scandisk and various disk defragmentation tools do not handle it correctly ;-)
Re:NTFS already does it since Win2K ! (Score:3, Informative)
Junction points, at least the ones created by the utility referred to, are in fact hard directory links. You can mount any directory from any NTFS volume as a directory at any point in any NTFS volume's tree, not just whole partitions.
I have used junction.exe many times to save a lot of reorganization by mounting a directory from one volume onto another when the other is full and there is no unallocated space to add. For example, you can move directories from "c:\Program Files" to "d:\Program Files" and t
Re:NTFS already does it since Win2K ! (Score:5, Insightful)
The problem with Junction.exe is that the Explorer shell and all other applications do not differentiate between links and real folders. That is, applications never expect two different paths to point to the same object, which makes Junctions much less useful in practice. For example, file search results take much longer to complete and display duplicate results. I believe that is why they initially limited Junctions to just directories.
Now, if Vista got persistent file handles, that would be interesting.
Re:NTFS already does it since Win2K ! (Score:4, Interesting)
Even more annoyingly, if you "delete" a junction point directory through the shell it will do a recursive delete just as it would for a folder, thus deleting all of the contents of the junction's target directory. If you set up the junction point then this is expected, but if it's someone else who isn't familiar with the concept they can easily mistake it for a bunch of duplicate files (since the shell displays them identically, and gives misleading disk usage information) and delete both copies.
Fantastic! (Score:4, Funny)
I had to check.... (Score:2, Funny)
NTFS already has symlinks, has done for years (Score:4, Informative)
New strapline? (Score:3, Funny)
Great... but (Score:3, Interesting)
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.
Re:Great... but (Score:4, Funny)
Multiple streams are an absurdity. "Ok contestants, repeat after me: 'A file is a variable-length array of bytes.'" Steve Jobs: "A file is two variable-length arrays of bytes." BZZT. "Sorry Steve, thanks for playing." Bill Gates: "A file is N variable-length arrays of bytes." BZZT. "Whoops Bill, that's a directory. Looks like you're out too! Join us next week on 'Who wants to be an architect!'"
Reparse points are more commonly known in the UNIX community as 'mount points.'
Re:Great... but (Score:4, Interesting)
Two are running Battlefield 2 servers 24x7, one is running a web server and a database server to aggregate statistics on players. All have been in service doing this kind of thing for over two years.
Never defragged, still running as good as new.
Lol, symlinks (Score:5, Informative)
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 [bell-labs.com]
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.
Re:Lol, symlinks (Score:2)
Re:Lol, symlinks (Score:3, Interesting)
For example, i have dozens of webapps deployed in their own directories, and they all need a configuration file in a their own directory. Since this config file is the same for each webapp, it certaily makes a lot of sense to have the file be a symlink to a real file somewhere else, in a kind of meta directory.
Re:Lol, symlinks (Score:4, Informative)
or rather, I'll just provide a link to this
The Use of Name Spaces in Plan 9
Rob Pike
Dave Presotto
Ken Thompson
Howard Trickey
Phil Winterbottom
Bell Laboratories, Murray Hill, NJ, 07974 USA
http://plan9.bell-labs.com/sys/doc/names.html [bell-labs.com]
Symlinks were a BSD invention (Score:4, Informative)
The commercial product, SysV, got symbolic links, but they had to compete in the real world.
Re:Lol, symlinks (Score:4, Informative)
You're confused. Files in Unix filesystems have no hierarchy, with or without symbolic links. Files are quite independent of file names. Multiple directories may contain entries for the same file, the names need not even be the same. The same directory may reference the same file with multiple names. Note for examples that renaming a file changes the modification time of the
Symbolic links are a bit of a hack though, yes. But mostly because they must expose the limitations of "files are not the same as filenames" - not because they allow multiple paths to the same file.
--paulj
Re:Lol, symlinks (Score:3, Insightful)
He never mentions hard-links at all, with which the namespace remains quite hierarchical and cycle-free. Symbolic links suck not because of the multiple-name thing, but because they're an implementation hack that both can turn the namespace into spaghetti and produce inconsistent results across applications due to how exposed their guts are to appl
Re:I think we have a new kind of troll... (Score:5, Informative)
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/ [swtch.com]
"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)."
Good grief! (Score:3, Funny)
not news (Score:2)
I expect even more "inspiration"... (Score:2)
And Microsoft, with its stance on patents vs copyright in software, already demonstrated it can do shameless 180 degree turns.
Microsoft: how much can you trust us today?
Gates on patents [corante.com]
So, will they also get hard links? (Score:3, Interesting)
MS Motto (Score:5, Funny)
How sad (Score:3, Insightful)
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
..and about time, too! (Score:2, Insightful)
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, i
FOUR, er FIVE symlink styles, all kinda *wrong* (Score:5, Interesting)
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!
Improve on symlinks? (Score:5, Informative)
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...
only way to improve on slinks is to get rid of FSs (Score:3, Interesting)
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:
The Fix: Aliases (Score:4, Informative)
Not the first time (Score:3, Interesting)
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 [spinnwebe.com]
Already has this (Score:3, Informative)
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).
Re:Already has this (Score:4, Insightful)
and of course the plain old short cuts that are really symbolic links in the traditional unix world.
Try sharing that shortcut over Samba. Didn't work you say? Then, absolutely nothing UNIX-like about it.
The unfortunate part is people still think of DOS/Win95
I use Windows XP and it still has lots of shortcomings. However it's multimedia support is waay ahead of Linux, and I use my machine mainly for multimedia. So whatever criticism I may serve, that's based on WinXP and modern Redmond-OSes.
Give me a feature in Unix and Im sure there is an equivalent in NT.
You'd think any serious server-OS would implement this...
A reinstall with the textmode interface doesn't count.
For whatever reason, increased security, lightweight editions, added native FS support...
Just to list a few. I do however have a job to do :-D
This is rich (Score:3, Funny)
Vista escapes the Matrix (Score:3, Funny)
*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.
Re:Ah yes (Score:2)
No. (Score:5, Informative)
Re:Ah yes (Score:5, Interesting)
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.
Re:Ah yes (Score:5, Insightful)
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.
Re:useful? really? (Score:3, Informative)
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 s
Re:We can only hope (Score:5, Informative)
Re:We can only hope (Score:3, Insightful)
I wonder if this attitude leads to all those race conditions when creating files in
Re:We can only hope (Score:3, Informative)
>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 an
Re:We can only hope (Score:3, Informative)
MS did it to themselves (Score:3, Insightful)
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 thirt
Mac OS X already does it the RIGHT way. (Score:3, Informative)
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: