Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Microsoft IT

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)."
This discussion has been archived. No new comments can be posted.

Vista To Get Symlinks?

Comments Filter:
  • Security risk? (Score:5, Interesting)

    by fm2503 ( 876331 ) on Monday October 31, 2005 @06: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:Ah yes (Score:5, Interesting)

    by strider44 ( 650833 ) on Monday October 31, 2005 @06: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.
  • Great... but (Score:3, Interesting)

    by Anonymous Coward on Monday October 31, 2005 @06:53AM (#13913752)
    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.
  • by WindBourne ( 631190 ) on Monday October 31, 2005 @06:57AM (#13913763) Journal
    My understanding is that NTFS does not use hard links (and the associated counts). If they are allowing symblics, why not allow hard links?
  • CYGWIN? (Score:2, Interesting)

    by the_instigator ( 679233 ) on Monday October 31, 2005 @07:14AM (#13913810)
    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.
  • by Ancient_Hacker ( 751168 ) on Monday October 31, 2005 @07: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!

  • Re:Lol, symlinks (Score:3, Interesting)

    by HawkingMattress ( 588824 ) on Monday October 31, 2005 @07:32AM (#13913867)
    Well one could argue that scrapping symlinks was a really bad idea. Yes they can lead to messy filesystems if they are used in a bad way, but they are also the only way to solve a myriad of problems.
    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. Then I can just edit this file instead of having to edit each copies. There is no way around this type of problem without symlinks. You have to make the thing less maintenable, more error prone, and futhermore you'll need to do more work, like maybe creating a script to copy the file in each directory.
  • Re:Security risk? (Score:5, Interesting)

    by IWannaBeAnAC ( 653701 ) on Monday October 31, 2005 @07: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.

  • by master_p ( 608214 ) on Monday October 31, 2005 @08:24AM (#13914029)

    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:

    1. files are strongly typed.
    2. user can have views of data.
    3. improved searching.
    4. improved indexing.
    5. transactional logic available to any application.
    6. huge model-view-controller over all data; monolithic applications no longer needed; better distributed environments.
    7. better security.
  • Not the first time (Score:3, Interesting)

    by basilpronoun ( 700414 ) on Monday October 31, 2005 @08:24AM (#13914032)
    MS have invented symbolic links before.
    http://slashdot.org/article.pl?sid=00/03/02/083321 1&tid=109 [slashdot.org]
    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]
  • by Nurgled ( 63197 ) on Monday October 31, 2005 @09: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.

  • by brennz ( 715237 ) on Monday October 31, 2005 @09:10AM (#13914248)
    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.
  • by arivanov ( 12034 ) on Monday October 31, 2005 @09:47AM (#13914469) Homepage
    That was about something more similar to hardlinks IIRC.

    I think it was only as an idea that was supposed to be part of XP. It was supposed to be able to replace multiple copies of the same file with a single reference with an increased refcount.

    I do not think it ended up in the shipping version.

    Even if it did it would have never given XP/2003 the same advantages as link reference counting gives to Unixes because of the differences in the locking model. Actually dunno... With some changes in the default way Windoze installs and deinstalls stuff it may have ended up being useful.
  • Re:Great... but (Score:4, Interesting)

    by LLuthor ( 909583 ) <lexington.luthor@gmail.com> on Monday October 31, 2005 @10: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.
  • by Anonymous Coward on Monday October 31, 2005 @10: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).
  • by Poltras ( 680608 ) on Monday October 31, 2005 @12:05PM (#13915473) Homepage
    May I remind you that vistas betas (i like the sound) just are contradicting with the bsd theory? For another note, see previous replier which has a point: everything you said was released thousands of years ago by hebrew microsoft employees.
  • by Anonymous Coward on Monday October 31, 2005 @12:44PM (#13915810)
    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).

    You can very well use a junction to make a directory on one partition/filesystem appear as a directory on another filesystem, junctions are not restricted to mount only partitions/system volumes as folders in a filesystem.

    Junction.exe from sysinternal proved very useful when my oracle installation grew out of c:\oracle; I moved the entire c:\oracle to e:\programs\oracle and made c:\oracle a junction pointing to e:\programs\oracle. No mounting of entire partition involved. Works like a charm, nobody noticed any difference and all references to c:\oracle in registry or wherever they may exist are still valid.
  • by Anonymous Coward on Monday October 31, 2005 @01:09PM (#13916096)
    Man, I LOVE /. posters.

    And I love how deceptive posts like yours get modded up as "insightful."

    > So you have three reports on /.

    No. There are _four_ report -- one each from PCWorld, EWeek, WindowsITPro, and the current one from Ward Ralston (three of these just happen to be linked on Slashdot). Plus, there was my fifth point about Microsoft porting .Net to BSD.

    So right off you start trying to deceive your readers.

    And you can't count.

    > One of them describes a feature that's been in Windows since NT 3.1 (and exposed as a public API since Windows 2000) (symlinks).

    First of all, the Windows NT "symlinks" have never been the same as Unix symlinks.

    Second, in the current article, Ward Ralston is talking about symlinks (Unix-style, from the description) as a NEW capability of Vista. Why we he be doing that, if he was talking about the old NT-style symlinks?

    By the way, Ward Ralston is a member of the Windows server team, so I suspect he knows more about it than you.

    > The other describes an existing feature that's been available for Windows since NT 4 and is now apparently being included in the OS base (SFU).

    Again, then why did Microsoft announce that they were SHUTTING DOWN SFU, because the new Unix capabilities would be BUILTIN to Windows?

    As stated by Samm DiStasio [eweek.com], director of product management with Microsoft's Windows Server division, "Having Unix interoperability functionality integrated in to the OS (operating system) helps customers to programmatically access Windows and Unix resources at the same time, which is super important and something that couldn't be done with the previous architecture."

    What new architecture would that be? Could it be... BSD?

    I'll give you one thing, you're more capable than the average astroturfer. Your attempts to deflect the issue sounded very believable. If Microsoft had more posters like you, their reputation as an innovator would be secure.
  • by Anonymous Coward on Monday October 31, 2005 @05:53PM (#13918453)
    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.

The hardest part of climbing the ladder of success is getting through the crowd at the bottom.

Working...