To read all comments associated with this story, please click here.
Vista has both symlinks and hard links. here is the output of mklink on my computer
Microsoft Windows [Version 6.0.6001]
Copyright (c) 2006 Microsoft Corporation. All rights reserved.
C:\Users\Matt>mklink
Creates a symbolic link.
MKLINK [[/D] | [/H] | [/J]] Link Target
/D Creates a directory symbolic link. Default is a file
symbolic link.
/H Creates a hard link instead of a symbolic link.
/J Creates a Directory Junction.
Link specifies the new symbolic link name.
Target specifies the path (relative or absolute) that the new link
refers to.
Ah I see, thanks for that!
I love being corrected when I'm wrong - it's the best way to learn!
So I guess then that hardlinks are designed so that if you overwrite it, the linked file itself is overwritten, and a special procedure is needed to remove the link.
Still, Explorer & any other app should still be able to realize when the file is a link rather than the actual file.
Thanks again :-)
--The loon





Member since:
2005-07-24
Geez... so Microsoft is saying that they are treating hard links exactly as the actual file, so much so that it appears that hard links are the same size as the original file?
That's kinda dumb. Maybe they should try BeOS, and just copy their symlink model.
I could very easily duplicate the winsx whatever folder in BeOS using MAYBE 1 MB of space, and it will be reported as such as well.
Symlinks are what Microsoft calls hardlinks, they are simply 'virtual' file system object which point to another file and which can act exactly as the file to which it points.
BeOS supports two types of Symlinks: absolute & relative, the only difference being how the linked file is located ( with an absolute path: "/boot/home/Desktop/someFile" vs "../someFile" ).
BeOS shows Symlinks as being what they are, and gives them a faint underscore to differentiate the real file from the Symlink. However, when a program blindly opens a Symlink the system just substitutes the linked file by negotiating the Symlink.
The difference is that it is incredibly trivial to determine if the file being dropped is a Symlink. So all Microsoft needs to do is ensure that they can do the same - trivially check to see if the file is a "hardlink" and treat it as such in Explorer until invocation or data access is required.
Operations that would be performed on a link versus the actual file are different, but some things will be common, such as size & name, those things will require special handling. BeOS does this with the BSymlink class :-)
Explorer should just implement a quick check to see if the file is a hardlink or not, and follow the BeOS standard of very subtle differentiation. Size in BeOS is assumed to be 0 for a symlink, but they still take size in the folder and report as such, accurately.
Oh well, that is the problem with numerous teams working on separate parts of a single product without enough intercommunication.
Personally, I think Microsoft could cure an incredible amount of their problems if they simply started feeding the final pre-release builds up to higher support teams, each team consisting of fewer and fewer members, until you get to a single person who would examine issues raised and determine validity of the issues, and be able to suggest fixes.
I'd do it, I know I could do it, I've done it in the past. Apparently people liked it :-)
Oh well, I turn down Microsoft's offers because I'd prefer to work right here from home :-) They can't pay me to move, either.
--The loon
... besides, my uncle used to work for Microsoft and they withheld pay for so long he decided to rob a bank to try and get by. He planned it out rather well, but the teller's car he was going to take wanted her house keys, so he wasted time getting the car key off the ring while the silent alarm was triggered. He got off with a slap on the wrist ;-)
Edited 2008-11-22 19:51 UTC