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)."
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?
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.
They are just not accesible from the shell. You need 3rd party utils to use them.. http://www.sysinternals.com/Utilities/Junction.htm l
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
$ 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 =)
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.
NTFS already had symlinks. Just that Explorer and cmd.exe didn't used the feature. But if created (with a third party tool) they are properly used.
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..
gtkaml.org
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.
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.
"Microsoft 'innovating' once again" - by el_womble (779715) on Monday October 31, @06:41AM
m l
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.ht
-----
Win2K's version of NTFS supports directory symbolic links, where a directory serves as a symbolic link to another directory on the computer.
For example, if the directory D:\SYMLINK specified C:\WINNT\SYSTEM32 as its target, then an application accessing D:\SYMLINK\DRIVERS would in reality be accessing C:\WINNT\SYSTEM32\DRIVERS.
Directory symbolic links are known as NTFS junctions in Win2K.
Unfortunately, Win2K comes with no tools for creating junctions - you have to purchase the Win2K Resource Kit, which comes the linkd program for creating junctions.
I therefore decided to write my own junction-creating tool: Junction.
Junction not only allows you to create NTFS junctions, it allows you to see if files or directories are actually reparse points.
Reparse points are the mechanism on which NTFS junctions are based, and they are used by Win2K's Remote Storage Service (RSS), as well as volume mount points.
If you want to view reparse information, the usage for Junction is the following:
Usage: junction [-s]
-s
Recurse subdirectories.
If you want to create or delete a junction, use Junction like this:
Usage: junction [-d] []
To delete a junction specify the -d switch and the junction name.
-----
(NT's been there, & done that, ages ago already for DIRECTORY SYMBOLIC LINKS @ least... + the resource kit tools mentioned above, OR the tools offered by Dr. Russinovich & Bryce Cogswell @ SysInternals do the job in this matter as well as alternate methods of using what's already been in NTFS for ages now)
APK
P.S.=> "and giving the people what the want (10 years after everyone else). Go Redmond!" - by el_womble (779715) on Monday October 31, @06:41AM
They surely have, now, haven't they & for the last 12 years or more @ desktop/laptop levels up to Server OS + backoffice/industrial strength tools to match their Office Suite offerings + development tools?
So, with that statement of yours, I must agree:
Plus, 95%++ of the world's computers running Windows NT-based Operating Systems by now (e.g.-> NT/2000/XP/Server 2003), which run tons more hardwares than UNIX of any type does, + with more peripheral surrounding softwares for any imaginable purpose (thus, Win32 Os are far more ubiquitous + flexible) can't be TOO far wrong to second your statement now, can they? apk
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).
I don't know where you got your info from, but plugging in a hotswap disk does NOT require a reboot, and hasn't since at least Windows 2000, but probably even NT 4. Open computer management, go to disk configuration, and click "rescan disks". It'll detect the drive just fine.
Geek used to be a four letter word. Now it's a six-figure one.
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 for the creation and handling of symlinks.
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
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
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.