Stories
Slash Boxes
Comments
Search

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Vista To Get Symlinks?

Posted by Zonk on Mon Oct 31, 2005 05:36 AM
from the sounds-like-another-os-i-know dept.
Microsoft IT
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)."
+ -
story
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Vista To Get Symlinks? 50 Comments More /

 Full
 Abbreviated
 Hidden
More
Loading... please wait.

  • Duplication... (Score:5, Insightful)

    by Erik_the_Awful (675368) on Monday October 31 2005, @05:39AM (#13913691) Journal
    ...is a compliment of the highest form.

  • Yet more great (Score:5, Funny)

    by Skiron (735617) on Monday October 31 2005, @05:40AM (#13913693) Homepage
    innovation from MS.

    • Re:Yet more great (Score:5, Funny)

      by Anonymous Coward on Monday October 31 2005, @05:44AM (#13913717)
      Yea, they better hurry up and patent it before those unix hippies copy it.

    • Funny thing is... (Score:5, Insightful)

      by WindBourne (631190) on Monday October 31 2005, @05:53AM (#13913748) Journal
      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.

      • Re:Funny thing is... (Score:4, Funny)

        by Keeper (56691) on Monday October 31 2005, @06:42AM (#13913914)
        No, in two years time everyone will be running around saying that MS copied it from Apple. Then someone else will jump in and say that Apple stole it from Unix. After that, someone else will claim that Apple stole it from Xerox. And I'm sure after further debate someone else will mention that it was originally an idea first postulated by the ancient greeks, before computers were even invented.

    • Re:Yet more great (Score:5, Funny)

      by kd3bj (733314) on Monday October 31 2005, @06:43AM (#13913919) Homepage
      What's next?

      Forward slashes?

      Text files without ^m's?

    • Re:Yet more great (Score:5, Funny)

      by Anonymous Coward on Monday October 31 2005, @07:23AM (#13914028)
      all your symbolic links are belong to SCO

    • Vista Will Probably Be BSD-Based (Score:4, Interesting)

      by Anonymous Coward on Monday October 31 2005, @09:30AM (#13914753)
      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.

      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 .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.").

      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 .Net, were all based on other companies' products, or were developed by teams hired from outside.

      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:Nevermind (Score:5, Insightful)

          by bcat24 (914105) on Monday October 31 2005, @09:16AM (#13914643) Homepage Journal
          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.)

        • Re:Nevermind (Score:4, Informative)

          by avdp (22065) * on Monday October 31 2005, @09:36AM (#13914790)
          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.

           

  • Allow me to be the first to say... (Score:5, Funny)

    by Noryungi (70322) on Monday October 31 2005, @05:41AM (#13913700) Homepage Journal
    Welcome to the 1980s, Microsoft.

    (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)

      by rolfwind (528248) on Monday October 31 2005, @05:48AM (#13913733)
      I'm sure that's what those Plan9 folks are thinking of the Linux/BSD camp^_^

        • Re:Allow me to be the first to say... (Score:5, Insightful)

          by mrogers (85392) on Monday October 31 2005, @08:29AM (#13914378) Homepage
          That after all those years Microsoft still has drive letters with a dirty hack (my desktop / my computer /whatever) to 'unify' them, has only broken symlink functionality (shortcuts), and only now mentiones symlinks is quite pathetic, if you ask me.

          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.)

    • Re:Allow me to be the first to say... (Score:5, Informative)

      by WWWWolf (2428) <wwwwolf@iki.fi> on Monday October 31 2005, @06:00AM (#13913771) Homepage
      (Who was it who said: 'Those who don't know UNIX are condemned to recreate it. Badly.' ?)

      $ 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 =)

  • Different than shortcuts (Score:5, Informative)

    by 246o1 (914193) on Monday October 31 2005, @05:42AM (#13913708)
    From TFA, before it gets slashdotted and someone asks:
    Well, a shortcut will only work when used from within the Windows shell, it is a construct of the shell, and other apps don't understand short-cuts. To other apps, short-cuts look just like a file. With symbolic links, this concept is taken and is implemented within the file system. Apps when they open a symbolic link will now open the target by default (i.e. what the link points to), unless they explicitly ask for the symbolic link itself to be opened.

  • "Virtual folders", I believe it's used for (Score:5, Informative)

    by Sockatume (732728) on Monday October 31 2005, @05:43AM (#13913709) Homepage
    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.

  • Security risk? (Score:5, Interesting)

    by fm2503 (876331) on Monday October 31 2005, @05:43AM (#13913710)
    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?"

    • Re:Security risk? (Score:5, Interesting)

      by IWannaBeAnAC (653701) on Monday October 31 2005, @06:37AM (#13913887)
      Presumably the security problem has something to do with symlinks that point to a file that the client does not have permission to read. If the server handles symlinks in a naive way, then on a request to open() a symlink it would open the target file (which is the usual behaviour of opening a symlink), but potentially with the wrong permissions.

      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)

    by Anonymous Coward on Monday October 31 2005, @05:43AM (#13913711)
    See here :

    http://www.sysinternals.com/Utilities/Junction.htm l [sysinternals.com]

    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:5, Informative)

      by TeXMaster (593524) on Monday October 31 2005, @06:40AM (#13913902)
      Junction points on NTFS are neither symlinks nor hardlinks: they are mountpoints for system volumes (partitions). Basically, they are the way NT deals with the Unix way of doing things (instead of the DOS way of assigning letters to volumes).

      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:5, Insightful)

      by astrosmash (3561) on Monday October 31 2005, @06:41AM (#13913905) Journal
      Rumors about real symbolic links in Windows have been swirling since before Win2000.

      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)

        by Nurgled (63197) on Monday October 31 2005, @08:07AM (#13914224)

        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)

    by Anonymous Coward on Monday October 31 2005, @05:45AM (#13913724)
    Symbolic Link and SMB2 - should I also be waiting for ZeldaFS and MegaMon?

  • NTFS already has symlinks, has done for years (Score:4, Informative)

    by Anonymous Coward on Monday October 31 2005, @05:47AM (#13913731)
    They are just not accesible from the shell. You need 3rd party utils to use them.. http://www.sysinternals.com/Utilities/Junction.htm l [sysinternals.com]

  • Lol, symlinks (Score:5, Informative)

    by DrSkwid (118965) on Monday October 31 2005, @05:54AM (#13913753) Homepage Journal
    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 [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.

    • Symlinks were a BSD invention (Score:4, Informative)

      by Per Abrahamsen (1397) on Monday October 31 2005, @07:42AM (#13914106) Homepage
      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.

    • Re:Lol, symlinks (Score:4, Informative)

      by Paul Jakma (2677) <paul+slashdot@jakma.org> on Monday October 31 2005, @09:08AM (#13914605) Homepage Journal
      Symbolic links make the Unix file system non-hierarchical, resulting in multiple valid path names for a given file.

      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 /directory/, but not of the file.

      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:I think we have a new kind of troll... (Score:5, Informative)

            by DrSkwid (118965) on Monday October 31 2005, @09:29AM (#13914740) Homepage Journal
            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/ [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)."

  • MS Motto (Score:5, Funny)

    by psiekl (310217) on Monday October 31 2005, @05:59AM (#13913768) Homepage
    We are the leaders, wait for us!

  • FOUR, er FIVE symlink styles, all kinda *wrong* (Score:5, Interesting)

    by Ancient_Hacker (751168) on Monday October 31 2005, @06:14AM (#13913812)
    So there's going to be FOUR ways to alias files and folders and volumes:
    • (1) Mapping a directory to a drive letter.
    • (2) Shortcuts.
    • (3) NTFS mount drive as folder.
    • (4) The new symlink thingy.

    oops, isnt there still:

    • the old DOS "subst" command too?

    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)

    by mcrbids (148650) on Monday October 31 2005, @06:26AM (#13913849) Journal
    There can be some improvement, particularly with managing symlinks.

    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 /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.

    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...

    • The Fix: Aliases (Score:4, Informative)

      by Rosyna (80334) on Monday October 31 2005, @07:59AM (#13914193) Homepage
      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).

    • No. (Score:5, Informative)

      by Virak (897071) on Monday October 31 2005, @05:43AM (#13913713) Homepage
      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 [wikipedia.org], for more info.

    • Re:Ah yes (Score:5, Interesting)

      by strider44 (650833) on Monday October 31 2005, @05:44AM (#13913720)
      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.

      • Re:Ah yes (Score:5, Insightful)

        by MichaelSmith (789609) on Monday October 31 2005, @06:06AM (#13913788) Homepage Journal
        The basis of it is that a shortcut is just a file

        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:Symbolic links? (Score:5, Insightful)

      by m4dm4n (888871) <madman@nofrance.info> on Monday October 31 2005, @06:06AM (#13913791) Homepage
      I don't believe that the word innovate was used anywhere except here on slashdot. While it's been a long time coming, the blog entry that originally posted this admits that all these additions are addressing limitations in SMB.

      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)

          by b100dian (771163) on Monday October 31 2005, @07:11AM (#13913989) Homepage Journal
          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..

        • Re:Symbolic links? (Score:4, Informative)

          by SonicBurst (546373) on Monday October 31 2005, @08:21AM (#13914319) Homepage
          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.

    • Re:We can only hope (Score:5, Informative)

      by countach (534280) on Monday October 31 2005, @06:19AM (#13913830)
      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.

    • Re:Great... but (Score:4, Funny)

      by gargleblast (683147) on Monday October 31 2005, @07:42AM (#13914108)

      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)

        by LLuthor (909583) <lexington.luthor@gmail.com> on Monday October 31 2005, @09:09AM (#13914610)
        MS does not inconvenience its users to defrag. I have been running several Windows machines for many years (still running Win2K on some of them), and I have honestly never defragged them.

        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.

    • Re:Already has this (Score:4, Insightful)

      by trezor (555230) on Monday October 31 2005, @07:58AM (#13914187) Homepage

      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.

      • Kernel and network support loading before the GUI?
        You'd think any serious server-OS would implement this...
      • Possible to recover the system without a GUI if needed?
        A reinstall with the textmode interface doesn't count.
      • Modular kernel which can be stripped of unneccesary features?
        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

All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 Geeknet, Inc.