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.
..and people say MS isn't innovative!
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!
I'm not sure a shortcut would count, since shortcuts are not application-transparent in the same way as symlinks.
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 ?
It took microsoft 29 years to figure this out.
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.
I hope they're carefull, this could break lots of programs that recursively browse a filesystem without limiting the max depth. Anyway, it's a nice feature to have, I've been missing it.
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.
"[...]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)"
So... they're implemented server-side in Vista then?
SIG: TAKE OFF EVERY 'CAPTAIN'!!
What's with all this talk of innovation? Is the *nix crowd feeling threatened? From what I gather, symlinks were introduced with the SMB2 protocol, and nowhere in the article does it claim that Microsoft invented either of these technologies.
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.
Since Windows programs have not ever needed to check for the existence of symlinks, a lot of software will be a serious DoS waiting to happen. Recursive symlink traversal is one of the most devastating things a computer can do to itself. It can damage hard drives, crash software, take down servers and generally make the computer unusable. On UNIX, almost all software is aware of this pitfall and won't go crashing the computer.
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
There have been soft links in ntfs since at least w2K, and probably NT4. I believe they're called junctions in the NTFS jargon. You need the administrative tools to be able to create them. And at least now they're kinda problematic in the sense that there is no way to distinguish them from real folder or files ince they've been created unless you bring up cmd.exe and check with junction.exe if they are indeed symlinks. So it would certainly be a good idea to integrate them better and have them in the main release. (Plus i don't know how it is now, but when i tried to install the administrative pack there was a big warning saying that you shouldn't do that unless your windows locale is english american, and that it was likely to cause unsupported problems if you did otherwise...)
... getting to Vista and coming from FOSS or *nix. Apple demostrated that incorporating free software has lots of advantages without hurting sales much, if at all. :)
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
---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol
they should be interpreted on the client side of a file sharing protocol (otherwise this can lead to security holes)
So if I call a Vista server from my Linux or WinXP box, the server will be as open as a sieve? Sweet.
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
which let you implement symlink behavior has been around since Windows 2000.
m l
In order to create them you can use junction.exe:
http://www.sysinternals.com/Utilities/Junction.ht
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...
All the 'M$ is just copying the OS of the Gods again' aside, and not doubting for a minute that symlinks are powerful little thingies, 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. Even under Linux, leaving OS-related symlinks aside, the only ones I have are in my home folder - they point to data directories on other partitions and their function is exactly that of a shortcut under Windows - they merely replace the clutter of folder shortcuts on my Windows desktop.
So, yeah, they are cool and more powerful than Windows shortcuts... but did anyone *really* need them?
... and they're still catching up with the basic features of UNIX. :P
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
No, it's not April 1st, it's halloween. Microsoft are trying to scare us all away from using Windows.
Ask me about repetitive DNA
NTFS had had symlinks for donkey's years. Have a search for "reparse junction" on Google. I use them all the time on my Windows systems.
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!
I don't quite understand, if I make a symlink called softs in a folder called share for example, of course i want the SMB clients to be able to follow the link as it is evaluated server side. It ain't a security risk, it's how it should be. Now if you do the opposite and have the client evaluate the link, yes you can have deep security issues since you can have the client do things on a file which he thinks is remote while he's in fact treating a local file... I hope the author just mixed up client/server concepts, or it will indeed suck...
It seems that Microsoft operating systems are getting closer to real world needs.
I wonder how did those engineers got this mind blasting idea!
Maybe Computers will never be as intelligent as Humans.
For sure they won't ever become so stupid. [VR-1988]
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.
n/t
I can see it already. Are these new symlinks going to be iso9660 compliant? Yeah right.
Join the Slashcott! Feb 10 thru Feb 17!
So in other words, shortcuts will work like they should have worked all along. What a concept. But only in the server edition. They'll still be broken in the other "editions." Smooth move.
Insert witty sig here.
My god, insted of ripping off a decent and challenging "unix like" innovation they are ripping off very simplisitic and straight forward ones. .. I wonder if ms will decide to actually implement VFS subsystems .. now that would raise an eyebrow! not bloody symbolic links ... all i got to say is a big .. PFFFFT!
BTW how come this earned a spot in the slashdot? GIVE ME SOMETHING REALLLLL!!!!!!!!
I'm not sure if they are the same as symlinks, hardlinks are duplicate file records in the FAT. You can create them in XP (maybe 2k?) with the syntax (from the windows XP help file):
fsutil hardlink create NewFilename ExistingFilename
Hardlinks cannot jump partitions though, that's why I'm not sure if they are the same as symlinks. If a hardlink is removed, the file remains until the last reference to it is deleted.
Send email from the afterlife! Write your e-will at Dead Man's Switch.
It really seems like somebody at M$ has said "what're the best bits of Linux (et al), and why can't we put them into Windows?" Hence we have the much-touted "Monad" shell thing, symlinks, ... But in fact they're not really addressing the Windows' real shortcomings as a server OS, just piling on more coats of paint as they often tend to do ...
"Those who do not understand UNIX are doomed BY Windows." --Anonymous Coward
Virtual folders are the single biggest change in terms of user tools, and a departure from the arcane hierarchical filesystem model. The point is not managing multimedia files without the Player, the point is managing ALL kind of files the same way (thus making the player application redundant).
iTunes and now Media Player have trained users into this information management way - based on libraries of similar items, and now its intended to be escalated to the whole system and replacing the old way (which was not good for tasks not related to OS programming, due to its many shortcomings).
Singularity: a belief in the "God" idea with the "demiurge" relation inverted.
Is it just me or have the people answering this post lost their sense of humor?
...is a compliment of the highest form.
Junction points do not work with files, only with directories, and don't allow you to reference directories in other units.
OK so NTFS gets symbolic links... it also has had hard links and multiple data streams for ages, unfortunately with the need for backwards compatibility, the vast number of FAT/FAT32 installs and the average user IQ, I have not yet seen any Windows software that actually uses these features, and it's not easy to see them in action even from the command line, unless you know what obscure Resource Kit tool does the job or what specific shell syntax supports the required feature...
Yeah, let me tell you - all you need in one other person with access to this box and any Microsoft tool that is not designed with knowledge of symlinks and wa'la! You've got hosed filesystems!
The problem is, most all of Microsoft tools don't just deal with the symlink (junction actually) as a simple file, they also link to the actual data and remove it too, not just the symlink, in a inconsistent way.
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'.
In good old Microsoft tradition, I guess this opens the door for a whole new class of vulnerabilities.
to read all the comments of the *nix zealots making fun of MS but actually pissing in their pants fearing there will be less and less unique points to brag about their OS. Well, do not fear! There will be enough things left that windows can't do.
I can always depend on Microsoft to innovate! God! I! Love! Microsoft!
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.
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
The Plan9 troll, that is.
Not dissing Plan9; It's clearly relevant as a research OS. But it's not relevant as a commonly-used or even well-known OS.
tasks(723) drafts(105) languages(484) examples(29106)
Any program that deletes files ought to be vaguely symlink aware, as you need to know whether you are following and deleting stuff under symlinks or not.
Case in point, Apache Ant has symlink awareness for its delete and copy operations (and others) which is a real dog to implement in Java, sun having chosen to hide symlinks and file permissions from the unworthy java developers.
-steve
as much as before but it would be cool if there could be interfilesystem links.
I one could do a link like
D:\ to C:\mnt\D
you could get a more unixlike hierarchy
errera hunamum ets
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).
File race conditions come from dumbasses doing a stat() on a file before creating it:
rc = stat( filename &statbuf );
if ( rc == -1 && errno == ENOENT )
{
fd = open( filename, O_RDWR | O_CREAT, 0600 );
}
Any decent programmer would do this:
fd = open( filename, O_RDWR | O_CREAT | O_EXCL, 0600 );
All in one line, to boot.
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.
Both Mac (through aliases) and Unix had symbolic links since forever. Why did it take microsoft so long to catch up?
Was it just microsoft not seeing the need to implement this or was there some technical/usability issue involved?
yet it seems MS is not allowed to add a feature unless they thought of it themselves.
While at the same time using licensing, proprietary code and patents to destroy real innovation by cutting off the base of the work, fund SCO to try and rip apart linux, yet never actually public admit to this.
That is what pisses me off, and continues to piss me off is that no reporter worth his salt has reported this.
Microsoft will litigate the hell out of projects that make linux too useful or easy to migrate within a windows shop. *cough* samba *cough*.
They also bundle things up - so they have control of key functionality. Name one consumer area of computing where microsoft doesn't bundle and destroy, against a competitor?
Even word/frontpage against dreamweaver.
I can only hope someone takes control of GIMP and NVU comes up with the goods so Adobe can go fusk themselves with their photoshop, 'digital negative' and now macromedia bumf.
GIMP needs a release that is gimp, but with less buttons, and less advanced features, and MORE basic features.
And programatic brushes (procedural brushes). OMFG I would even write those if it wasn't written in an ancient programming language. bah.
The GIMP or K's art package, I will check them out again tonight, and see how they fair.
#hostfile 0.0.0.0 primidi.com 0.0.0.0 www.primidi.com 0.0.0.0 radio.weblogs.com
Anyone have the link to Microsoft's patent on this technology?
You know they have one. You just know they patented some twist of how they do this that's different than how UNIX does it, but it's worded so vaguely that it could apply to UNIX if a lawyer wanted to read it that way.
"Live Free or Die." Don't like it? Then keep out of the USA
So I have a directory on my Win2K box named "d:\collected", and in that I have directories for all the various items I have collected- video, music, pictures, software, etc. SOMEHOW, I managed to create a folder named "collected\music" that resides at the root level of the D drive. It just points directly to the "d:\collected\music" directory. If I try to delete it, I'm pretty sure it will delete my music collection, so I don't want to do that. If I try to rename it and delete the "\", it tells me "Cannot rename music: You cannot specify a different folder or disk when you rename a file or folder". If I try to rename it without removing the "\", it says a filename cannot contain the "\" character. So, basically I've just left it there. It's only really a nuisance when I run WinDirStat, because it ends up showing the music directory twice. Anyone know how to get rid of it?
I have been waiting for years for this, this is an excellent innovation by M$...oh wait...I use linux...
When all is said and done, nothing changes...
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).
"When shortcuts were invented for Win95 the Win32 API should have been built to treat a shortcut as the object it pointed to."
Actually OS/2 Warp 3 had them around 1993-94 ( can't quite remember ). They were called shadowed files and folders. Of course when Microsoft used them in Win95 and called them shortcuts they were being innovative. =]
Well. So does FAT, except it is called a crosslink, and aparently scandisk and various disk defragmentation tools do not handle it correctly ;-)
How about RedHat Bob, or Suse ME! Or do something weird like bring out a free Office Suite!
soylentnews.org Go there to enjoy the people!
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!
As I said in this old comment:
"Given enough time and money, eventually Microsoft will re-invent UNIX." (author unknown)
Now once they start working on the GUI and come up with something that's more useable, maybe closer to the NeXT or OSX, Microsoft might even have a real Linux competitor!
Assorted stuff I do sometimes: Lemuria.org
You can only trash and recover files using Explorer, while the shell doesn't know anything about it in both way. Is noone missing the word "consistency" in these cases?
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.
Situations like directory paths to the same location in the filesystem are the only spot where I can see this abiguity really being a big issue. As long as there's some way for me as a human to tell that one configuration file is just a symlink to another, who cares? Yeah, a less-than-clueful user might make some screw-ups if they're using symlinks improperly, but that's not a compelling argument to me - it could be turned against the delete command, too.
Why not just take away symlinks to directories? They're really most useful for files, anyway.
The shortcut file type was created because the filesystem people and MFC people didn't bother to talk to each other for some reason or another. Windows is full of these inappropiately placed api's because of ignorance, lack of communication and architectural control, or just somebody creating their own little api empires. Probably all three but mostly the middle. Microsoft can't even keep the sape api's consistent across different releases and platforms. The Xbox 360 is really going to be screwed up because of this since the particular api in question is notoriously difficult to use and debug as it is.
... what's the main difference from a symbolic link in Windows Vista, and a normal shortcut from Windows 95/98/2k/Me/XP? With shortcuts you can link a file to another file/drive/folder from another filesystem/server. I think they are just trying to think up things to add to their already small 'feature' list.
Sig: I stole this sig.
In other words, shortcuts will work like they are supposed to now. I have always wondered why Microsoft screwed that up.
I'm pretty sure Apple had 'aliases' in MacOS somewhere before MS had shortcuts in Windows as well.
Why are power users left out? This is a potentially useful feature for everyone, and they only put it in Longhorn server? I know some users would do completely idiotic things, like somehow manage to move the swapfile on a floppy and symlink to it while trying to burn some mp3's, but why not include it disabled by default and leave an entry in the registry to enable it?
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..
I read the article and it answered my question. Now I have a new one: Why couldn't an app just open the .lnk file, find out the destination, and then follow through in the first place? They are only changing the behavior of something that already works fine. Microsoft seems to be doing this with a lot of things, and simply calling behavior changes new featues. I mean in Vista you click start, and press R to select run, but realize that an R is put into a search field built into the start menu. How is making minor changes to the behavior of the OS/Shell make the company innovative? People don't like change, and long time windows users had a hard time moving to XP, but the behavior was similar to that in 98/2000, so people were able to accept it. Now it's like they are saying, "We didn't screw it up this time, lets try again with delayed releases and redesigning the interface to be even more resource intensive and clunky than before!" It seems like they are taking their time to make sure every dialog is updated and completely different from their previous generation of software, so that when it comes out, it will all be the same under the hood as Windows NT 4 with tweaks to make it run a little more efficient on the latest hardware, and it will look so malformed and act so sparatic, it will seem like a new product all together.
Sig: I stole this sig.
But what about an executable flag?
Mac OS X has symlinks, hardlinks, mounts, and aliases (two kinds?). As a practical matter, it doesn't seem to be a huge problem.
I had a feeling this was coming eventually. This is one feature that UNIX really kicked Windows' but with. Run out of space on a critical volume and you could always link to a new one. As others have noted, this is more of Microsoft catching up. Like AD, some Window's-centric noob will be touting this as a great new thing.
the vista kernel is codenamed winux (sounded better than wunix or winbsd)
I agree to some extent.
But... A database is a file system, and a filesystem is a database.
You're in fact opposing hierarchical data organization to relational data organization.
I suppose Reiser4 is the way to go...
I have discovered a truly marvelous proof of killer sig, which this margin is too narrow to contain.
Two types of links that work in different ways? I don't think anyone will stand for that. Do you suppose they'll call them 'hard links' and 'soft links'?
Microsoft: "Who Do You Want Us To Copy Today?"
-or-
Microsoft: "Innovation Through Imitation and Intimidation"
But isn't "subst" the same thing as mapping a directory to a drive letter? Isn't it just a different interface to the same functionality?
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).
NAME SYNOPSIS DESCRIPTION RETURN VALUE
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Has nothing to do with symlinks at all. The important question is, will SMB2 finally use the underlying verification for correctness when being sent across authenticating protocals (ala TCP/IP).
I hate the fact that I can FTP a file between windows boxes at approximately 10x the speed that I can "copy" them in explorer.. At the very least, the mid-level (API) copy functionality should do the determination itself as to which method *should* be faster, and do the appropriate thing.
I currently have no clever signature witicism to add here.
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?
IIRC, the whole OS/2 WP shell operated in an alternate universe from the filesystem, and "shadows" only existed in some binary database file somewhere.
Whenever I hear the word 'Innovation', I reach for my pistol.
Well it's about time. Leave it to Micro$oft to be a fews years late as usual. (IDIOTS)
ln -s /dev/null /boot/vista.bz2
enough said
One application of this idea:
.lnk files from one machine and put them in the c:\documents and settings\all users\desktop folder on the new machine to make them available without having to recreate them.
Suppose you have a category of shortcuts that you want to be available on every user's desktop when the machine is set up (file shares, so forth and so on). On Windows, you can just copy the
That being said, I MUCH prefer symlinks.
SYS 64738
I know fortune, and I still have to ask about the single quotes...
They're only a few years behind, no biggy.
:-().
Seriously, though, I've been wanting this for years.
Shortcuts just don't cut it (get it? Sorry.
- Agilo
symlinks are cool, however mix it with the way windows programs are installed and there WILL BE CHAOS
....
I can already see XYZ company selling symlink cleanup tools for all the programs that link to all over the windows SYSTEM dirs...
On the other hand programs could ONLY place a symlink into a shared lib dir and keep the DLL in their installation dir... at the end it could be a decent thing too
I wanted to criticise and just realized that it could be useful to clean some mess up at the end
Where the hell did you go to school?
New Vista file system == UFS?
Vista as a Mach3 identity side-by-side 4.4BSD?
Security tool that lets normal users obtain admin right: admindo?
"Oh, magic crystal orb that shows me the path to go,
where does that orange glow come from and what is that coax cable in your back for?"
Maybe in 20 years their toy operating system will catch up to where UNIX is today. Don't think UNIX will be standing still in that time, though! But at least by then I suppose Windows will be somewhat useful. I suppose I can't really hate them though. If they went out of business, pretty much the entire security industry would collapse overnight. Millions of people who have built their jobs around Microsoft's crappy security, instantly out of work! It'd be the dot-com bust all over again!
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
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.
Make that six: As another contributor pointed out there is also Crosslinks...
Oh well, what the hell...
am i the only one who got this?
"But isn't "subst" the same thing as mapping a directory to a drive letter?" That's the problem, it looks like the same thing, but has wildly different effects. In the old DOS days, "subst" was done by hooking the BIOS disk I/O calls and blindly mapping the drive indices. About 20 lines of asm. Worked swell, except when certain programs went straight to the disk controller. Then you'd end up backing up or formatting the wrong disk. ----- Mappng a drive uses the barely documented file system redirector calls. Very different animal from "subst".
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.
I always used Luigi, the higher jumping was invaluable on most levels.
Depends what you're doing, and how picky you are.
If you're trying to index a whole file system. it's a huge pain to have two files with different names but pointing to the same data. Or a file that is actually a remote filesystem, which may or may not be available, may be 1000 times slower than the rest of the files.
Or if you're trying to write yet another smart backup program and don't want to backup multiple copies of the 44GB database, just because different users have different shortcuts or mounts or aliases or substs to the same data.
Or if you're trying to write a virus checker.... Regards, A_H
There is a move command in the shell. But I am thinking at the completely wrong level?
SymLinks are psuedo supported in Windows (although not by the file system) in the guise of shortcuts, although I'll admit a shortcut is a far cry from a symlink
I haven't really tested it, but the unxutils package includes an ln binary.
Isn't there a POSIX layer for NT that would require symlink ability? This is probably just unused capability that is already built into the OS.
Would you be so understanding if a TV manufacturer suddenly claimed "innovation" because they finally decided to offer color TVs? In 2005?
Because that's just about what Microsoft is doing with symbolic links.
Thanks MS! That's actually my biggest gripe about windows other than the price. Bring the price down to $50 a seat for EVERYTHING and I'll be able to forget about linux.
It looks like the article is describing something somewhat different from symlinks. That said, NTFS since Windows 2000 and on has already had the capability of doing symlinks through Reparse Points. Indeed, this is how mount points were done. Perhaps not the most efficient way to do things, but it works just great, and it's far more flexible than symlinks.
sigs are a waste of space
When Microsoft is doing their best to make Windows more like *nix!
HTTP/1.1 400
Are Plan 9 users the new Ubuntu users (who were previously the new Gentoo users)? ;)
...because that filesystem is actually DOCUMENTED, meaning other operating systems can actually read and write to it without having to blindly trust some blackbox implementation of a filesystem driver.
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
If they are links to absolute paths. Because file systems aren't always shared at the same point in the tree as they are originally.
Honestly, MS' shortcuts are exactly like symlinks. They're just a file with a special bit set that you open and read to get a redirect. The only difference is the servers/clients don't interpret them. The server passes them on unmolested and the client (on Linux/Mac) doesn't bother to interpret them either.
Also, it is stealing. Were you out there fighting when people talked of stealing cable? How about stealing a kiss? How about stealing away to a secluded place? Face it, English overloads words constantly, this is just another case.
http://lkml.org/lkml/2005/8/20/95
If you actually read the article you linked to, you'll see the problem is with the stupid way that Unix implements these things. Since symlinks were hacked onto Unix as an afterthought, they don't preserve Unix semantics. That is, the command "cd /home/rob/.." doesn't take you to "/home" if rob is actually a symlink because it goes to whatever inode the ".." link points to on whatever filesystem rob is mounted from. On Windows, though, "cd \home\rob\.." will always take you to "\home" because, just like Plan9, it doesn't have the same braindead implementation as Unix.
dom
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.
Ahem...
We have hundreds of those over here, and we're not alone in the universe...
Linux user since early January 1992.
I have a bad feeling that somehow this will be a cause of MAJOR security hole
Virus may simply cause symlinks to various important files, and let the administrators fsck their own files
I don't think windows is ready for the concept of sym links yet
I may be wrong, but we'll just have to see
Symlink - Noun. More commonly called a 'Shortcut' by Windows users.
Apart from having a similar effect, the NT subst command has nothing in common with the DOS subst command. NT subst simply adds a new symbolic link to the internal device namespace.
In the wrong hands, symlinks are a handy means of rendering an otherwise clean system unmaintainable. I've seen this plenty of times on *nix boxes which were sloppily maintained.
:-]
I can't wait to see what happens on Windows.
Who cares... I'm sure this will be very useful to the gamers, cube weenies and home office crowd.
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.
Windows is finally implementing true file system path aliases. This is not ambiguous with Shortcuts.
'Shortcuts' are more than just an encoded path. 'Hotkeys' can be associated, 'starting directory' can be designated, arbitrary icons assigned, etc. The *nix analogy is found in any contemporary X Windows GUI shell (Gnome, KDE, etc.) with their various dot file structures defining menus and/or launch parameters for GUI applications.
Windows had the GUI application metadata 'link' first and got symlinks second. *nix got symlinks first and then blundered into Shortcuts (doomed to forever lack a uniform manifestation.) I think this just highlights the different priorities of the platforms.
Lurking at the bottom of the gravity well, getting old
I disagree. Shortcuts are more like an alias than like a symlink, which gives you the ability to do things that hardlinks and symlinks don't do. For example, a shortcut can run the target as a different user, specify the working directory for the target, run a command with a command line, specify console colors for console applications, specify an icon to dispay when showing the link, specify how to show any window that the target displays (minimized, maximized, etc), and other things.
Given that, they have their place and are useful even when you have hardlinks and symlinks.
Believe it or not, they already work at the Windows API level. Yes, CreateFile, etc. take forward slashes when opening or creating a file.
Even meaner, there is a way to call CreateFile that accepts backslashes as ordinary characters (FILE_FLAGS_POSIX_SEMANTICS or something like that). Have fun with your admin that way.
then there is the even older DOS ASSIGN command...and Windows 9x "Long Filenames" ... and APPEND, and all sorts of other symlink wannabes.
Make America grate again!
Windows NT has had the form of links needed for Posix compliance forever. XP has both hard and soft. They're not exactly easy to create, but the support is there.
What Windoze needs is to get rid of those pesky drive letters. Implement support for legacy apps, but get rid of C:, D:... there's another *nix thing that's been around for ages. Now I know Windoze does have junction points BUT drive letters are still there.
NTFS has had junctions for a while. They act very similar to SMB links, and you can get a utility from sysinternals to manipulate them.
C:\>dir *.
Volume in drive C has no label.
Directory of C:\
07/06/2005 11:08 AM <JUNCTION> desktop
03/03/2005 10:52 AM <DIR> Documents and Settings
10/26/2005 02:33 PM <DIR> Program Files
10/28/2005 10:27 AM <DIR> WINDOWS
...is a complement of the highest form.
/deterioration!
I am scientifically inaccurate.
I'm pretty sure, I can predict first seroius overflow bug. It's a symlink to parent directory.... :)
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer Usenet signature, November 1987
Does that mean I can finally do something like
ln -s filename1 filename2
via GNU Utilities for Win32 under Windows Vista?
coz last time I used ln in WinXP, it says:
ln: symbolic links are not supported on this system
fing dhu.
> saying that MS developed it,
SCOG will be saying that _they_ developed it and will sue MicroSoft for all Windows revenue they ever collected or $50 billion whichever is higher, _and_ will require all Windows Vista users to buy SCOG licences at $795.00 per user.
Wait.. I know it..
Wine
Of course! It's all a conspiracy of the wine-developers to make a huge, ugly and powerful MicroSoftDaemon!
This is pure genius! We should all buy stock in wine now!!
Why is it that we hear another story about Vista every day now, and yet the software is still in a very speculative state ? Do I really care what bullcrap the insider-of-the-week imagined when he repeatedly smacked his forehead against the desk this morning ?
Vista will be whatever Vista is when it is released. There have been more features dropped than added and all this media spin is sounding like the Weekly World News and their alien transgendered babies.
"We're going to do this, we'll revolutionize that".. why don't they just shut the hell up and build it already. It's just a freaking GUI, not rocket science here.
-Billco, Fnarg.com
As far as an application is concerned, there are only 3 different kinds of symlinks:
/dev/kmem or /dev/sda0, what what about /proc? There's no function you can call that will tell you whether something is a real file or a virtual one, so your program is SOL.
1. Object manager symlinks (1 and 5 are both drive letter mappings)
2. Filesystem symlinks (3 and 4 are both NTFS reparse points)
3. Application symlinks (shortcuts are imlemented by OLE)
If you're writing an end-user application, you probably only care about application symlinks if you care at all (because standard dialogs follow them for you). The advantage of shortcuts is that they can track their target if moved to another directory, or even to another computer!
If you are writing a system utility (such as backup or indexing) you have to pay attention to filesystem symlinks (like in Unix) because you can choose to follow them or not. But otherwise your burden is no different than without symlinks because the existence of hard links means that you already have to keep track of which filesystem/file number combinations you have already processed.
Now if you think that's bad, imagine how much worse it is on Unix. The proliferation of filesystems has made it so that you don't even know what's really a file and what isn't. Only a truly naive program would try to backup and restore
dom
Hot lesbian action.
Why do you think CodeWeavers pushed so hard to change the Wine license? It certainly wasn't to help Linux. They knew that the change would prevent Windows Games software from using Wine to run on Linux (hence the Transgaming WineX fork).
Why do you think CodeWeavers has been concentrating mostly on Microsoft applications? And how do you think Crossover got the information necessary to make Office run properly, when no one else had succeeded? And why do you think Microsoft has never complained about or threatened Crossover?
And let's not forget about Microsoft's partnership with VMWare.
All the pieces are in place for Microsoft to put a Windows application layer on top of BSD, and OSS developers helped build those pieces.
But it won't be perfect, of course, which is why Microsoft has been warning us about Vista incompatibilities.
NTFS has had support for links for a very long time. MS has provided command line tools to create links since early NT days. "DIR" even identifies them specifically as a "link" instead of another unique folder. The "news" here is that the explorer shell and SMB will now support links. If this wasn't Windows, it would be a "big deal, next please" type of article. However, it is quite fashionable to pounce on Microsoft, so we must endure countless posts poking fun at MS. If MS didn't add this support, we would endure countless other posts complaining that it doesn't support this. Damned if you do; Damned if you don't.
Partition Magic 1.0 through 6.0 or so was able to do FAT16->HPFS conversions in place without any need to move the data. Rather slick.
People forget that it started life as an OS/2 utility.
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
How quaint.
-- If we don't stand up for our rights, now, there will be no right to stand up for them later.
Hierarchical data organization can exist inside a database by using one or more links in the same table or in a different table.
Baby steps, man... baby steps.
File under 'M' for 'Manic ranting'
http://www.pearlmagik.com/winbolic/
The term you're looking for is "DBMS", since the filesystem is *already* a database.
But yeah, relational filesystems would rock it hard. However, it doesn't seem like the IT industry can even build a proper relational DBMS *application*, I would shudder to think what crap they would create if they tried to build it at the OS level.
ever tried:
dir "c:/windows"
on a commandline. supprise, suprise.
The "'\' vs. '/' - well have both!" idea comes from OS/2 and NT has inherited it.