Slashdot Mirror
Vista's Limited Symlinks
An anonymous reader writes, "Symlinks haven't really been added to Windows Vista. It seems that the calls to the Windows Vista symlink API only occur during the creation of such files or when accessing them from Windows Explorer. What this means is, you can't access symlinks from another OS. To be fair, you probably didn't expect to be able to dual-boot into XP and suddenly have access to the symlinks you created on the Vista partition earlier that day. But then again, you probably expected to be able to access these symlinks through a network share/UNC path or as files on a webserver. But you can't." From the article: "Clearly, Vista's symlink API isn't complete — hopefully this is something that can be patched via a hotfix and that we don't have to wait for Fiji to get something as simple as UNC support built in."
Time to call in the code inspectors.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Vista's limited.
Theory is often inaccurate(TM)
"Those who do not understand UNIX are condemned to reinvent it, poorly." -Henry Spencer
PHP has encountered an Access Violation at 7C8224B2
Let's get real. If the OS was perfect nobody would buy the next version. I bet that 80% of purchases are made by people that secretly hope there's finally a version of Windows that just works.
:-)]
[and there's of course the not-invented-here syndrome - maybe symlinks are GPL-ed?
... not when the ability to successfully resolve something may depend on things handled by the directory/metadata structure, with tagging that is indeed OS-specific.
MacOS has had aliases since System 7 and they're far more useful than a unix-style symlink ever has been for me -- in part because everything that needs to open a file on the Mac uses the MacOS APIs. POSIX is "closer to the metal" and therefore pays a price in lost features of abstraction.
If you want Unix-style utilities to work with the new Vista symlinks, then patch the damn copy of "ls" yourself. And then submit it to the FSF.
Hire a Linux system administrator, systems engineer,
You can't squirt files across OS's yet.
No, what is being discussed here is links, e.g., creating an additional filename referencing an inode.
4 1355
http://win32.mvps.org/ntfs/lnw.html
http://en.wikipedia.org/wiki/NTFS_symbolic_link
http://answers.google.com/answers/threadview?id=3
NTFS does support links, but as usual from Microsoft, it's half-baked and only the bare minimum required for POSIX compliance was implemented. From sysinternals (now a Microsoft site) you can download a utility for manipulating NTFS links, or you can install the free Services for Unix (again, from Microsoft's web site) to get the M$ version of ln.
The Christian Right is Neither (Christian nor right). See: Matthew 23, Matthew 25, Ezekiel 16:48-50
Link, please.
... and then they built the supercollider.
Your information about MS half-baked implementation of links only applies to Windows XP. Vista introduced true UNIX-style symbolic links in addition to the junctions introduced in earlier versions of NTFS. The new links were incorporated from Windows Services for UNIX. See my posts on Vista Symbolic Links from a month ago. http://wesnerm.blogs.com/net_undocumented/2006/10/ symbolic_links_.html
http://wesnerm.blogs.com/net_undocumented/2006/10/ symbolic_links__1.html
A couple of days ago, the ranting of some MS manager about interoperability, here on slashdot. But when it's time to ship, having working symlinks (rocket science apparently) for basic interoperation purpose is not there. Same old Microsoft, expect same old frustrations with Vista.
---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol
Windows 2000 promised administrators the ability to manage everything from the command-line. That turned out to be true mostly for a small list-of-old-DOS-utilities value of true. Additionally, we were offered junctions/mount-points which sortofkindof worked, but weren't fully supported. Sysinternals offered their 'junction' utility which worked a bit better, but again, not really. Now with Vista have SFU or SFU-as-subsystem that promises everything that Windows Scripting Host promised and more!
I expect that whatever hodge-podge of new features, one-off Resource Kit utilities or whatever else Microsoft decides to offer in their latest and greatest, I'll continue to rely on the folks at Cygwin to take advantage of whatever limited functionality exists in Windows, and then implement workarounds for the inconsistencies and shortcomings to make something useful and sane with it. In the meantime, I'll bet my right monad that a future Slashdot headline will read Vista's Borked NFS Client.
People are asking questions about VISTA Symlinking on MSDN. See this thread. The Vista symlink seems to have not much more functionality than "shortcuts" did in Windows 95 or Windows 98.
The issue at hand is why was the API left so incomplete that remote accessing a share that utilizes Vista Symlinking does not work? This is a large oversight on Microsofts part, and basically makes Symlinking useless. Fortunately, Symlinking works great via Samba. Another reason to stick with Linux..
Yahma
ProxyStorm - An Apache based anonymous proxy service for security minded people.
22 bloody years...
<nelson>haha!</nelson>
fucktard is a tenderhearted description
You website has also said goodnight...Maybe it's running off of Vista...May we suggest, erm, Linux?
When all is said and done, nothing changes...
Vista introduced true UNIX-style symbolic links
The article is about how it doesn't.
"When I first heard Daydream Nation it quite frankly scared the living shit out of me." -- Matthew Stearns
Yeah, they may be a huge corporation with some of the best computer scientists in the industry, and you would expect them to be able to get it, but even though they don't, IT SHOWS GOOD SPIRIT THAT THEY TRIED.
I have freaks! I did something right...
I can't RTFA because of web error, but while I haven't tried Vista's idea of symlinks, I have used junctions, which were introduced in Win2000. To me, symlinks are one of the best features of Unix and on my Mac and Linux machines, I use them quite extensively. On Windows, while the junction API was available, no Microsoft-specific tools made use of them (that I could find), and resorted to a freeware program that implemented the junction api.
Whoa, big mistake. Junctions *do* work, but, and I think this is why Microsoft didn't promote or encourage their use, none of their other tools support them. In other words, doing a search of a drive that has junctions can lead to infinite recursion depending on how the junction is created. No Windows tools understand the "Don't follow symlinks" command that Unix tools have, and I had a few programs even crash whenever I tried to save to a junctioned-folder (Visual Studio was guaranteed to crash on me).
"A witty saying proves nothing." - Voltaire.
It's official. Most of you are morons.
... that /. can find about Vista then Microsoft have won.
--I thought I was wrong once, but I was mistaken.
Is there a difference between them this week? I haven't been keeping up.
http://michaelsmith.id.au
Shortcuts are ill-conceived "placecards" for files and executables; like a road-sign, they can become outdated by changes to the target file and don't necessarily reflect any relevant properties of the target. The Windows95 implementation marks the change from a centralized database of "links" on the system to independent, "shortcut files". Neither implementation was directly linked to the filesystem.
Symlinks are directly tied through the file-system (not through a secondary API); in my analogy, a symlink is more like GPS navigation, it takes you all the way to the target.
Best-in-show would go to MacOS for aliases; more like a portal to the target, and if the target moves, the alias corrects itself.
In effect, the Windows-style "shortcut" is a complete dupe of *nix symlinks, (which came first) only bastardized and "extended" by M$ engineers. The fact that MS-DOS (ergo, Windows) used FAT file system negated the possibility of using symlinks. The data-structure was so simplified, there was no room left for advanced tagging or linking mechanisms. (already present in 'ext' at that time)
It's been years since MS bought several (disputed) Unix patents from SCO, and it's apparent they're still not making anything useful of those. Another case of wrecking already-working code for the sake of thumbing their noses and saying "It's original code! You gotta pay us for it now!"
Any wonder why they named it "shortcut"?
This post © Copyrite Duggeek, all rights reversed.
Try this and a ext3 file system. I have all my Documents and the whole user directory on an ext3 and it works great. I can also access it from Linux if I want...
Only on Slashdot can a first post be redundant...
There are plenty of other OS's they could base thier OS off, maybe even VMS.
Unix is far from perfect, I want choice but when Linux fanboys here choice they think it must be a choice which distribution you use, because Linux is the only choice.
Back to the line about VMS, because NT was built by a bunch of ex-DEC guys, the NT Kernel isn't that bad.
I mean, they could always port GNU userland over to the NT kernel, but dont MS already do that (or something similar) in their UNIX resource thing, which you can download.
There are two types of people in the world: 1) those that can extrapolate from incomplete data.
Link, or do not link. There is no 'try.'
Domestic spying is now "Benign Information Gathering"
There's plenty of other worse things about Vista; this is just an amusing side note.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
What are you talking about? Both Windows 2000 and Windows XP already have built-in support for symlinks (NTFS 5.0). What does all this have to do with Vista?
Back when I worked in VMS I got invited along to the local DEC HQ and recieved a lecture from some MSFT guy on how much NT is like VMS and that we should all run NT on alphas.
He asked for questions and I ask him why NT doesn't have proper vms-esque device names (dka0, etc). The question didn't go down very well. I supose that would break too much stuff.
I can't imagine them working on GPL'd stuff and having to release the code.
http://michaelsmith.id.au
Symbolic links can also become outdated if the target moves. It's hard links that can't.
Microsoft didn't buy the "patents", they "licensed" them. The only funny thing is that SCO owned (and maybe still does) only one patent, and it has nothing to do with operating systems :-P Neither SCO nor Microsoft ever claimed that Microsoft actually purchased patents, nor does the Wikipedia article you linked to.
The license covered Unix code as well as far as I can tell, most of which is in the public domain, and the remaining bits owned mainly by Novell and other parties.
I don't think its right to just attack Windows Vista because of a few problems. I mean it is not perfect and will not behave exactly the same as Linux, and this is Slashdot, but Microsoft, as a commercial entity, has done a good job providing a quality OS for computer users. Microsoft, no matter how much you may think they've "lied, cheated, and stealed" their way to the top, only has the profitability and money they have due to consumers. And they do make legitimate attempts at patching their OS and working towards improving it. I've also had about 6 Coors Lights tonight since its the weekend.
They cannot break legacy code but Apple gambled and did it, and I think it succeeded. Subjectively I know more and more people who ditch their Windows machines for Macs or even Linux.
Apple didn't have as big of a catalog of software to abandon.
I bet a lot of the Linux crowd would jump ship quickly if they could play DVDs, mp3's, run Photoshop and Office on it, while still having their command prompt, the network stack and ext3/XFS etc.
I just played a DVD from Kubuntu's live incarnation yesterday. I have been running MP3s on Mandrake and RedHat for at least 7 years. Photoshop is still a huge hurdle. Office alternatives (especially for home users) have been plentiful for years.
LK
"Hi. This is my friend, Jack Shit, and you don't know him." - Lord Kano
Rubbish - a corporation with large financial and technical resources such as Microsoft doesn't half-implement a simple OS concept like symlinks because they are simply unable to do it properly.
It's their OS, they know all the dirty little secrets of their code and they can make it happen if they want to. Rather, I suspect it doesn't suit them to have a completed api at present.. in fact I'll even hazard a guess that (unsurprisingly) their motivations in this matter will be less to do with product quality or customer satisfaction and more about whatever FUD campaign is currently coming up to the boil in Redmond.
..Mullah or Pope, Preacher or Poet, who was it wrote: "Give any one species too much rope and they'll fuck it up"?
Kaetemi
So this means that Windows still isn't ready for the desktop? Perhaps the next version after Vista then...
This space unintentionally left blank.
I remember back from the beginning of 90's, around the time when Windows NT 3.11 came to markets, that vision behind NT was that it would be as modular as possible and allow swapping of lots of components beginning from the kernel to file-system. This was actually reported in lots of computer news papers, but it seems from now that it was just hype and hopeful wishes. Now it seems that the code base of NT and it's successors is so mingled that trying to swap components from it would make the system die in a split second.
Survey research tool for commercial and scientific use
Why this obsession with UNIX?
I think that was more an example of something they could have done - basically a good choice, even though there are others.
The main problem I see with Microsoft is the incredible degree to which they duplicate something that already exists:
* Operating system, as noted they could base this on UNIX or something else and saved a lot of effort.
* Filesystem - why does the world need NTFS? There are other really good file systems around. If it offered features like ZFS I could see it but about the only FS I'd like to use less than NTFS is FAT, and that's actually a better choice for small devices because it's simpler!
* Display format - PDF ain't good enough for Microsoft, hell no, we need a brand new document/display language. Metro!
* Porgramming langauges. We can't extend Java just the way we like without community review? Screw you all, we're building a new ball from scratch and running home!
* I think we need an XML based document format. It's not like one already exists or anything, let's create one from scratch!
Think of how far the industry as a whole would be along if Microsoft actually contributed to any of those fields instead of devoting huge numbers of resources to creating anew. Microsoft single handedly has set the computer field back probably a decade or more.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
There are ways around but most applications out there are still installing themselves in C:\Program Files and windows goes into C:\Windows and so on.
I mean, they could always port GNU userland over to the NT kernel, but dont MS already do that (or something similar) in their UNIX resource thing, which you can download.
You are referring to POSIX I presume. Well, have you seen any native Unix code running on Windows lately? I didn't! Windows POSIX compliance is a joke, it was more of a marketing ploy to tell their client ("we even run Unix!") but in reality it is very broken. That is why you have Cygwin...
And what happens in that alternate universe when they do that, and suddenly are unable to differentiate themselves from dozens of other nearly identical systems? Guess they stop being an OS company, huh?
Any sect, cult, or religion will legislate its creed into law if it acquires the political power to do so.
That's the story of Microsoft. Everything half-ass works. POSIX is working but is also not working. Symlinks work but don't work. Security works but not quite. I think if they had done what Apple did and just used a well tested free Unix-like kernel or a complete VMS implementation with a good network stack and security they could have been further ahead today...
IT SHOWS GOOD SPIRIT THAT THEY TRIED
:-)
Sorry, but that use to be the kind of patting on the back you give to children who come last in a competition.
Beware: In C++, your friends can see your privates!
Reality check: I don't hear large crowds of desktop users ask for proper symlink support.
In that case, proper Windows software (including game) compatibility is more important.
Beware: In C++, your friends can see your privates!
If you rm a one link to an inode, (or close a file descriptor), it reduces the inodes usage count by one. When the count reaches zero, the blocks referenced by the inode are marked free. The behaviour you describe would be utterly horrendous.
As the GP suggests, the Services for Unix package contains a lot of GPLed stuff, the code for which is also available on the Microsoft FTP servers. Microsoft have no issues with actually following license terms if they are required to do so.
It also sounds like a puppy granting wishes but that isn't what the article is about.
That so called "shortcut" feature that has been around since Windows 3.1 isn't a 'link' as it works on POSIX complaint systems. It is a shortcut that gives the user - not the computer - a quick way to access a directory. It cannot handle I/O functions.
if you steal from one source, that is plagiarism, if you steal from many, well, that's just research.
Compare Mac OS X. It has two different kinds of symlinks. It has the traditional, pure-quill, UNIX symlinks which work exactly as UNIX users expect.
It also has Mac OS "aliases," introduced IIRC in System 7, which most Mac devotees think are superior to UNIX symlinks.
Now, before I get too far into praising "aliases," let me acknowledge that the presence of both mechanisms in Mac OS X is a big, hairy, ugly, mess, and one of innumerable places where the Mac world currently suffers from having anywhere up to half a dozen or so APIs for the same basic functionality. Mac OS X now resembles, well, my house, with fifteen-year-old half-abandoned dusty possessions still lurking in the attic. Not that Windows is any better, of course.
But I digress. You may like Mac OS aliases or you may dislike them, but you can see they they are a complete, well-thought-out, finished, working mechanism that it is at least possible to admire as something more than a half-baked knockoff of symlinks.
I happen to like them, a lot, because they just work. You don't need to do anything special at a programming level to dereference them, and it doesn't matter what programming language you're using or whether you're accessing them across the network, or whatever. However you do it, when you open the alias, you open the file it points to. And they are not fragile: you can move them or rename them or whatever and they still point to the right place. (The tough part is not dereferencing them... and Apple's deliberate failure to document or provide an API for creating them programmatically).
What I find hard to forgive Microsoft is that when Microsoft implements their knockoff of a well-known OS feature, it is rare that they come up with anything fresh and original. So many of their derivatives seem to be hasty knockoffs implemented by people who didn't "get" the original. And they put these half-baked implementations into shipping products, making it very difficult for Microsoft ever to finish them or fix them.
You can see this in a dozen places, like the Windows NT command language, which is a half-baked extension of the miserable quarter-baked DOS command language. Jeez, guys, you had DCL and the various UNIX shells as models, couldn't you do better than that?
And five years later, there tends to be conflicting documentation: the documentation written when badly-designed feature X was introduced, telling all good little Microsoft developers that they simply must, must, must use feature X in everything, and the documentation written a few years later warning everyone against the bad practice of using crufty old deprecated feature X...
I just wish I could shake Microsoft by the scruff of the neck and say, "Listen, if you can't improve it, then at least make a faithful copy of it."
Don't just pee in it to give it that personal flavor.
"How to Do Nothing," kids activities, back in print!
When I said "And they are not fragile: you can move them or rename them or whatever and they still point to the right place," what I meant was that you can move or rename the targets they point to without breaking the link.
"How to Do Nothing," kids activities, back in print!
So from the article, I gather it won't be possible to place a symlink on a shared directory that points to a directory on the machine that mounts the share?
We use this for a call recording system already. We mount a share via NFS on a NAS box. On that NAS box there is a symlink from a subdirectory of the NFS share to a path that doesn't exist on the server, but does on the client (the server stores the call audio, the client stores the call metadata). When the client mounts the share, the link works correctly, it points to the directory on the local machine.
This is damn useful since we can't change the behaviour of the call recorder (it expects the calls and metadata to be in the same directory). It seems this implementation won't allow this kind of transparency...
-- Sig Sig Sputnik
I'm slightly confused - hard links have been in NTFS for years, and I've use them a few times for various tasks, so why is NT so bad in relation to others? I'm also not sure why shortcuts are different to symlinks. Don't both just store a pathname to link to? If the target changes, the symlink/shortcut still points to that named file, or if the target no longer exists, both shortcuts and symlinks no longer work? Or am I misunderstanding? Your analogy doesn't seem to work - the key difference as far as I can see is that symlinks behave as if they were files in every way - shortcuts are just signposts for Windows Explorer. Assuming you're using Explorer, they seem to work the same.
As for Mac OS X aliases being 'best of class', the only time I needed to use one of those I found it didn't work over SMB sharing - exactly the same sort of complaint as is being levelled at Vista, as far as I can tell. This was a few revs back of OS X, so maybe it's fixed now.
When NT was created Microsoft knew it'd break compatibility but be superior to the existing stuff. Maybe Microsoft should treat the current NT line as a legacy OS (effectively making Visty the new Windows 98) and create a new OS completely from scratch.
I mean, how often did they have to scrap major parts (or even everything) of Vista and start over? At least twice, I think. Windows is getting unmanageable and I somewhat doubt that the NT kernel is in a better state. If Microsoft first developed a structured approach to OS building (unlike the 1000-developers-and-minimal-communication hodgepodge they have today) and then created a completely new kernel and userland parallel to Vista they might impress their users like they did when they introduced the NT kernel to home users with Windows 2000. They might even surprise people and write an OS that actually gets some respect from IT professionals.
I think Blackcomb could very well become the next Me - with or without a superior alternative being developed.
USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
Is OS X like the dozens of other *nix systems? Well, "Yes" and "No". It has all the core features but has enough of its own. It combines the stability, networking and security of Unix + the Apple GUI. Last time I checked, it is doing pretty well even among the other dozen or so "similar" operating systems. The point was that Microsoft could have been the Microsoft (support lots of software and hardware) and the Apple (have a stable, no-nonsense core operating system) -- it could have had the best of both worlds, in my hypothetical parallel universe.
top left corner
"I am a software developer in Seattle, building a new AI software company. I used to work at Microsoft on Excel"
every day http://en.wikipedia.org/wiki/Special:Random
User your drive letters!
"subst" working since MS-DOS 3.0
Saying your "phone ran out of batteries" is like saying your "car ran out of gas tanks".
Sheesh, stop talking about some of this banal Vista crap. Just let people know that Vista has no compelling reason to upgrade. This is a no brainer. I'm not being harsh nor trying to shut anyone down but these endless posts about little defects certain tend to color the fact that there's no reason to buy Vista, unless you want to have the latest stuff from Microsoft. If people want am OS that is solid and inexpensive that runs on a multitude of platforms then they should run Linux. Not that I am a huge Linux fan but it has to be definitely cheaper and requires alot less upgrading than buying Vista and installing it and then getting very little for the exchange of money.
So, please stop tossing little things that tend to color over the bigger issue: There's no compelling reason to buy Vista.
You can lead a man with reason but you can't make him think.
And guess what happened: each year a larger percentage of desktops were taken over.
"When I first heard Daydream Nation it quite frankly scared the living shit out of me." -- Matthew Stearns
Hardlinks are what Unix had *originally*, so they are even older. Symlinks were added later, as in fact hard links were very hard to manage. Permanent hard links are almost never used on Unix today (they are used for short-term things such as renaming files atomically).
There are "semi hard" links that Mac OS (but not OS/X?) do that may be better than both symbolic and hard links. They act like hard links as long as the linked-to file exists. If it is deleted they then act like a soft link (not sure if they revert to the original name or to some name computed from the most recent location). If a file is created at the soft link location they then go back to acting like a hard link.
Oddly enough, even though people pretty much admit that hardlinks are not as useful as symbolic links, Microsoft has done *more* to emulate hard links than symbolic ones. They are actually copying one of the more useless and harder to emulate Unix features, and not what is needed, which are symbolic links which are trivial to emulate. They are of course desperately afraid of making it too easy to emulate a Unix environment on Windows, and will do anything, including make up bogus excuses about the difficulty, to avoid it. This is also why Notepad still craps out if there are bare LF in the file and inserts a "utf-8 bom" at the start to break any Unix utilities that look at the first bytes.
Can't believe people are still actually using that PoS program that MS calls notepad. Been using Metapad for ages : http://liquidninja.com/metapad/
Apple has the luxury of marrying its OS with great hardware and design.
As pointed out, MS doesn't, and in fact MS has to support every POS software/hardware combination on the planet. Without that level of polish (which MS hasn't shown it can do anyway) and integration, MS's version would just be YAN (Yet Another 'Nix).
Any sect, cult, or religion will legislate its creed into law if it acquires the political power to do so.
Rubbish - a corporation with large financial and technical resources such as Microsoft doesn't half-implement a simple OS concept like symlinks because they are simply unable to do it properly.
Having worked for fortune 500 companies, I would say that you are giving them more credit for wisdom than is usually the case.
The environments I have see they usually:
1) Have a host of managers who have a poor grasp of what they are managing
2) Tend to go with the lowest bidder when contracting out for services, e.g. outsourcing programming and IT teams. This means monkeys usually end up doing thier software development and IT work.
3) Are run on an industrial paradigm, even in service industries. A 'let's ship tons of crap to make money' while ignoring the quality of the crap.
4) Managers make decisions based more on ego than business cases.
5) Treat people as commodities, leading once again to the hiring of monkeys to get critical tasks done.
6) Anything flash, regardless of utility takes precedence over the less sexy but often import details. E.g., nice new eye candy for Vista but a half-assed file system.
I have also worked in SME environments. I have observed that the larger the company, the dumber it gets. Larger compaies have plenty of places where dead wood can accumulate, can lose money at a rate that would sink an SME it short order and attract politcal people who know how to shift blame.
I have helped my current employer, an SME, grow to the point where it is getting too big for me. I am seeing the dysfunnctional aspects begining to develop. It is time for me to move on.
But all-in-all just because the company is big does not mean it possess an special wisdom. Esp. a monopoly which does not have to compete.
putting the 'B' in LGBTQ+
Aliases should work via SMB, so long as you've still got the resource fork and are accessing it from another Mac. They don't work from Windows for obvious reasons -- Windows has never implemented a volume-ID to path resolution required systems, as is required by the alias structure.
I'll give you that this makes aliases less flexible, but aliases give you the ability to make a link to a file on a disk image on a remote disk -- and rename any of the files, disks, or folders involved -- while still being able to double-click to open. All of the necessary mounting and name correction just happens; it's like a hard-link but without the need for the file to be on the same disk (or even local).
> In effect, the Windows-style "shortcut" is a complete dupe of *nix symlinks, (which came first) only bastardized and "extended" by M$
.PIF file is?
engineers.
Oh wow, you spelled MS with a dollar sign. Aren't you clever. Were you even born long enough ago to know what a
Oh but hey Unix invented filesystems, right?
Done with slashdot, done with nerds, getting a life.
Hardlinks AND symlinks have been in NTFS forever, but because you can't create them through the GUI or the DOS prompt, most people don't knwo they exist. Shortcuts are very different from symlinks, as shortcuts are just a GUI thing. If a program is hard-coded to look for "C:\foo\bar.ini" you can't move bar.ini elsewhere and replace it with a shortcut, as bar.ini.lnk isn't helpful. You can replace it with a link, however.
To create a symlink (or hardlink) in NTFS you either need to use Unix services for Windows to get a command line, or use the POSIX compatibility engine programatically (just make the same API calls you would in UNIX though random function names will have leading '_'s just to make it difficult).
Socialism: a lie told by totalitarians and believed by fools.
This post covers it all: http://www.osnews.com/permalink.php?news_id=16524& comment_id=183548
A local-to-local symlink is one that I open from my own machine that points to another file on my own machine. As the post mentions, local-to-local symlinks are on by default. No problem there.
A remote-to-local is a symlink on a network share that points to a file on my own machine. Local-to-remote is a link on my machine pointing to a network share, and remote-to-remote is a symlink on a network share pointing to another network share. All of these have security implications.
For local-to-remote, a critical system file could be replaced to point to a spoofed copy on a network share. For remote-to-local, I could wind up copying or deleting files from my own hard drive without realizing it. For remote-to-remote, I could think I'm accessing a safe server, but I'm really being redirected to an unsafe server without realizing it.
Of course, if all of these features are turned on via group policy, you have full, classic symlink support (target always resolved by the client, and Win2k and XP clients can't resolve them).
Communism was just a red herring.
... although not on Windows, obviously.
Subversion clients above version 1.1 on *nix systems which support symlinks are quite happy to support them, although it's a bit of a kludge.
The SVN repository filesystem itself has no concept of the symlink, something which remarkably enough, Visual SourceSafe *does* support. The "Share" command in VSS is about the only thing I miss about it when using SVN.
I *don't* miss the period repo crashes, the inordinate sensitivity to network outage, and the propensity of VSS to allow you do do horrible things to your data without even warning you.
And of course, if anyone really finds a feature missing from SVN to be really boiling their noodle, they can always code it up themselves (programming skills / cash to pay for developers may be required.).
Please tell us how you cd to a shortcut, then we can all agree with you.
.desktop file, not to a filesystem symbolic link.
A shortcut is analagous to a KDE
Try again.
The Christian Right is Neither (Christian nor right). See: Matthew 23, Matthew 25, Ezekiel 16:48-50
Actually I wish Linux would have the same thing, at least the hardware makers would clearly label which products work or don't work with Linux just to make it easier to shop. I don't care if such and such a device doesn't work with Linux, I just want that clearly shown so I don't have to return it after wasting a whole day trying to install it.
By the way, Sun's Solaris is also working great with hardware it was tested on, but as soon as you try to install it on a generic PC, there will be countless problems with not finding such and such a driver.
I've got mod points, but I just had to comment.
That's probably the most insightful approach to new Windows OSes that I've seen yet. The only way it'd be better is if you can convince MS to come to your school and have a launch party for something they are putting out.
When I was a student, we had MS come to our campus to have a launch party for VS.NET. Just for signing up for the presentation, you got a full copy of XP PRO, full copy of VS.NET and were entered in a chance to win one of 2 xBoxes with 5 games...(oh... and this was 2 months after the xBox Launch).
Cliff Claven
K.E.G. Party Chairman
Founding Leader of: Koncerned for Egalitarin Governance
Why does it have to be something the average user will want in order for it to be implemented? That's a backwards attitude to take, when you consider all the people like me who would love to play around with something like symlinks but can't. Or all the people who would like to be able to edit video or pictures on their PC and not have to spend $600 or more on software for that... wait, I guess I could just go get a Mac.
I could set up symlinks from my music and other media on a seperate partition to portions of the start menu. That's another thing that pisses me off about Windows, that 90% of the features they have in it are completely hidden and all of them default to situations which do not apply to me or actually make it harder for me to use my computer. Like the My Music and My Pictures and My Documents folders are all linked to a folder on my C drive, which is not the storage drive on my computer and default to a directory structure which I do not like. I can move the reference to the documents folder elsewhere, but the Music and Pictures folders stay right where they are, nested inside the documents folder. I've had to hack the registry to get the references changed.
It's that kind of half-assed implementation that drives people nuts. Why do they keep releasing new versions of Media Player and Internet Explorer when they can't even make an OS that's consistently useful for everyone and includes more than the run of the mill feature set?
SRSLY.
or is that *too clever?
My turnips listen for the soft cry of your love
Any Computer Science student can get free copies of all MS OSes (including the datacenter editions), their dev tools, and a load of other stuff (not Office or Virtual PC for Mac though, sadly). I grabbed a copy of XP from them to play some old games I still had.
I am TheRaven on Soylent News
OS X still supports them, and they are exposed through the /.vol hierarchy (or, more sensibly, the Carbon APIs), but their use is now discouraged.
I am TheRaven on Soylent News
It's slightly odd that it should be this way around, since Microsoft typically does everything it can to make developers lives easy.
I am TheRaven on Soylent News
"They cannot break legacy code but Apple gambled and did it, and I think it succeeded."
Apple didn't abandon Copeland for Unix, they abanodoned Copeland for NextStep, which happened to run on a bsd variant. Apple didn't give a damn about Unix. If they could have actually completed Copeland, they would have gone with that. If NextStep had been built on top of something else, Apple would have gone with that (and there was some consideration to go with the version of NextStep that ran on NT, but Apple didn't want to be dependend on MS in that way). Unix is a side-effect of the NextStep deal.
And those "moving to Mac OS X" aren't doing it to move to Unix, they're doing it to move to Mac OS X. And what makes OSX OSX isn't Unix, but Cocoa/Carbon, which "real" Mac apps are written to (meaning, the apps that normal people use; normal folks don't use "Mac" apps written against Unix).
I wish that Copeland had succeeded, so there would be at least one mainstream OS that wasn't built atop Unix or NT. More diversity in OS design advances the state of the art. You, on the other hand, are advocating that *every* mainstream OS be a Unix variant, as if Unix is the be-all and end-all, which is fallacy.
-- "I never gave these stories much credence." - HAL 9000
What you are saying is generally the consenses at osnews.com (having read their version of this thread).
-- "I never gave these stories much credence." - HAL 9000
How? From the University? Wouldn't that be individual policy?
If you double-click a text file on a standard Windows install you will get Notepad. Otherwise the problems with Notepad would not matter.
I am quite convinced Microsoft does this on purpose so that files imported from Unix will look like crap, and if you save the file it will break on Unix. Wordpad, Word, the IDEs, and almost any other program they write does not have this behavior, but the default one you get for text files does. What other explanation is there?
Microsoft already does that; it's called the Hardware Compatibility List. But the users haven't and won't learn that it's a good idea to follow, because when they see the $60 HCL-certified webcam beside the $17.95 Taiwanese-manufactured POS, they will choose the cheaper one. Every time. At least the manuals for these things tell Windows users what to do when Windows says "This driver sucks!" after installation.
I mod down pathetic posts.
The university provides the student with a number, authenticating them as a student, which allows them to download the software from Microsoft. The cost to the institution is zero, and all departments I've visited have been part of the scheme, even if they don't use Microsoft products on any courses.
I am TheRaven on Soylent News
on this note, is there any good non-geek article i can use to show people the difference between the two? i must not be that great at explaining some things (i know the difference myself, but i mean a simple analogy type article thing.. my employers love them). :)
Wow, talk about paranoid. Notepad exhibits that behavior because it's just a thin wrapper around the standard text box control. Remember when you couldn't load any files bigger than 64k in Notepad? That was because of an OS limit too. The standard text box isn't meant to be a full-featured text editor. Notepad's flaws are the result of laziness, not malice.
Here's another nail in the coffin of your theory: how many people could there possible be who import text files from Unix systems--or who even know what Unix is--but still aren't sophisticated enough to figure out how to open them with Wordpad (or good old EDIT.COM), which has no problem with Unix line breaks?
Visual IRC: Fast. Powerful. Free.
> Why this obsession with UNIX?
As Mike O'Dell once observed, while Unix is not without its flaws,
its file system is not one of these.
--tom
I was using it from a Windows machine, but I was confused (and still am after your explanation), as to why aliases didn't work over SMB. You say it's 'obvious'. I thought an alias was a file system level object, from what I remembered when I read about them in 'Inside Macintosh'.
So, to me, it's irrelevant that Windows has never implemented a 'volume-ID to path resolution' system, as you're doing network sharing, so you already have a virtualisation layer present. If I use Windows to open a folder shared on a Mac via SMB, and that folder has an alias to another folder on the Mac, why doesn't that just appear as a standard folder via SMB? Isn't that the point of aliases? They 'just work', because they're low enough in the FS system to just work as files or folders? Obviously, if you want to, you can detect aliases (so, e.g. you don't back up the same folder twice in a backup program), but claiming it's the fault of the client machine or the network protocol seems a bit lame.
SMB supports files and folders, so aliases should 'just work', even over SMB. The fact that they don't seems to me to be the same failing as Vista is being berated for in this story.
You have to be administrator to create symlinks in Vista. It's really lame.
Melissa
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
Ah, thanks for clearing that up - I thought that NTFS supported symlinks for ages, too, but the article and comments seemed to suggest it was new, and I was only sure that I'd use hard-links before (I just download one of the hardlink command-line utilities/explorer context menus whenever I need to use links), so I assumed I was wrong about symlinks.
And yeah, shortcuts are quite sucky due to the .lnk thing.
You do realize how that works, right? XP can mount an ext3 FS, but only as ext2. That means no journaling. That means FAT-like [in]stability.
Don't thank God, thank a doctor!
You don't understand the difference between hardlinks and symlinks. Try again.
A hardlink has the behavior you describe. A symlink is a file which refers to another file by name, not by inode. You can have multiple hardlinks to the same symlink, as the symlink itself is just a file, and a separate file from the one it links to.
Don't thank God, thank a doctor!
Windows Vista now implements symlinks directly in the filesystem....API. And it does so in a way that breaks over networks and OSes, which is what TFA was about.
.lnk files are actually more useful than these wannabe symlinks, because you can actually make them work on network shares, across OSes, and so on -- basically, anything that understands the .lnk file -- although they generally contain the full path, making things somewhat more difficult. But, symlinks are actually likely transparent to anything on the same machine, meaning your software follows symlinks by default, whereas it does not follow .lnk files by default -- you'd have to code that yourself.
This means that
And neither of them is actually part of the filesystem in the way that symlinks are on Unix.
So basically, Windows Vista (a version not out yet) is trying to approach where every Unix has been for at least 10 years, and failing miserably. Is anyone surprised?
Don't thank God, thank a doctor!
Not quite non-geek, but an amusing read even if you're all over hardlinks, symlinks, etc.: http://shell-shocked.org/article.php?id=284/
First, if an alias was purely a file-system-level object, I don't see why you think it would work across file systems. The native file system of Apple OSes is HFS or HFS+; SMB is another animal altogether. Even if HFS implemented aliases in the manner you imagine, it still wouldn't work via SMB, just as symlinks don't work on SMB, since SMB doesn't provide support for either mechanism. If it was a native file-system object it would limited by the scope and functions of the file system on which it was contained.
That's not to say aliases aren't tied into the file system -- they contain information native to whatever file system(s) they reference, and in that respect are part of the file system. But their scope is wider, so they cannot be considered native objects, as an single file system may not contain sufficient information to resolve them. They are however, a native part of the VFS on Apple OSes, so from the perspective of anyone using an Apple OS, they are a native object, just as symlinks are part of the linux VFS and therefore can be used even on file systems that do not natively support such an object.
Aliases do "just work" over SMB, so long as the system mounting the SMB file system supports aliases. You can make aliases to files and folders on an SMB share, or store aliases on an SMB share, and any system that knows how to read aliases will happily resolve them for you. But aliases are not a native part of SMB sharing, so simply having an SMB client implementation is not sufficient to resolve aliases.
Aliases are not superior in all cases to symlinks or hard links, but they are very useful for users creating links to files or folders, particularly if you may not have all the appropriate paths mounted, as is often true with remote disks or disk images. They are similar to the new system Vista is providing, but they are resolved at runtime in a manner that can transparently resolve changes in file paths and disk locations and names.
True, it was a licensing purchase. Another directly related article does point out SCO's claim. I'm sure many would appreciate it if you would cite your sources when making such specific claims, I know I would.
The summary of Linux controversies clearly shows that M$ put an interest into SCO's so-called "patent rights" in mid-2003... though the scope of the licensing is only a fraction of what Novell acquired from AT&T. (and still holds today) Certainly not enough for SCO to back-up their own notion that they "own" Unix.
Regardless of Novell's current Linux offerings, the fact that they have a succinct hold on the origins of Unix has a yet-to-be-determined impact on the future of licensed Unix platforms.
Add to that, they've got into bed with M$, and there's but a hint of what was actually purchased with the $350 mega-bills. Though Microsoft has their "Q&A", Novell is apparently all aglow about the new agreement.
This turns out to be off-topic, I know. I truly want to leave FUD aside with all this, however the details are speaking more loudly than my keystrokes could ever accomplish. This issue is already part of Novell's wiki entry and even throws some props to us /.'ers.
Besides, symlinks are damn useful. Unlike shortcuts, they have a distinct file attribute, but do not behave like their target (an advantage, to be sure); shortcuts are nothing but special files, and can be surreptitiously re-assigned to a new target, even a URL. Just check out these vulnerabilities regarding their use. I haven't seen any such problems with symlinks.
This post © Copyrite Duggeek, all rights reversed.
It's worse than that - they exerted effort to axe programs aimed at fighting Al Queda. If they had just left well enough alone, 9/11 may not have happened.
"We returned the General to El Salvador, or maybe Guatemala, it's difficult to tell from 10,000 feet"
To back up which claims? That SCO only holds one patent?
4 65903012299/j2045_10q.htm
4 _03_n-sco.pdf
Simply search for them at uspto.gov (the site doesn't let you link directly to search results or patents for some odd reason). The only patent currently held by SCO is:
Method and apparatus for executing multiple JAVA(.TM.) applications on a single JAVA(.TM.) virtual machine Patent # 6,931,544
As for the claim that SCO licensed code to Microsoft and not patents, I refer to SCO's own SEC filings, and what only they can only modify and edit as opposed to Wikipedia's policy of allowing any random tom, dick and harry to edit entries.
From the filings:
We initiated the SCOsource effort to review the status of these licensing and sublicensing agreements and to identify others in the industry that may be currently using our intellectual property without obtaining the necessary licenses. This effort resulted in the execution of two license agreements during the April 30, 2003 quarter. The first of these licenses was with a long-time licensee of the UNIX source code which is a major participant in the UNIX industry and was a "clean-up" license to cover items that were outside the scope of the initial license. The second license was to Microsoft Corporation ("Microsoft"), and covers Microsoft's UNIX compatibility products, subject to certain specified limitations. These license agreements will be typical of those we expect to enter into with developers, manufacturers, and distributors of operating systems in that they are non-exclusive, perpetual, royalty-free, paid up licenses to utilize the UNIX source code, including the right to sublicense that code.
The amount that we receive from any such licensee will generally depend on the license rights that the licensee previously held and the amount and level of our intellectual property the licensee desires to license. The two licensing agreements signed by us to date resulted in revenue of $8,250,000 during the April 30, 2003 quarter and provide for an aggregate of an additional $5,000,000 to be paid to us over the next three quarters. These contracts do not provide for any payments beyond 2003, except that Microsoft was granted the option to acquire expanded licensing rights, at its election, that would result in additional payments to us if exercised. In connection with the execution of the first license agreement, we granted a warrant to the licensee to purchase up to 210,000 shares of our common stock, for a period of five years, at a price of $1.83 per share. This warrant has been valued, using the Black-Scholes valuation method, at $500,000. Because the warrant was issued for no consideration, $500,000 of the license proceeds have been recorded as warrant outstanding and the license revenue reduced accordingly.
http://sec.gov/Archives/edgar/data/1102542/000110
Nowhere in the filing does it mention any patents being licensed whatsoever to anyone. Once Novell started demanding royalties for these licenses, SCO told everyone it was a patent license, despite their SEC filings saying otherwise.
http://www.novell.com/licensing/indemnity/pdf/6_2
It happens quite often that SCO's SEC filings conflict with their public statements and court filings.
Novell has recently filed for an injunction against SCO, stating unequivocally that those agreements were source code licenses and thus Novell gets 95% of the revenue. Novell states that the license is a copyright license.
You bet your momma's table-sized hard-disks. While there may be contentions of technical accuracy, I postulate that Bell Labs Unix provided the groundwork for just about all enterprise filesystems in use today. (also about the time I was born... so yes, I do remember)
There's a distinction to be made here... a PIF file is not a "link" in this context. It can however be called a "launcher"... since it specifically contains data relevant to the environment for an executable.
While it does have a way to "Find Target", (Win95+) it ultimately gets left behind (broken) unless updated by installer applications or the user. Read carefully and you'll see that it's even older than LNK files; all the way back to MS-DOS.
Linux also distinguishes between links and launchers, however the differences don't give much potential for abuse. (unlike LNK/PIF files) The only exception is the symlink race vulnerability, but is a marginal risk at best with current security measures.
I'm sure that nobody forgot the beloved PIF, but who really considers them to be "links" anyway?
This post © Copyrite Duggeek, all rights reversed.
"When I first heard Daydream Nation it quite frankly scared the living shit out of me." -- Matthew Stearns
ahh, yes. SFU is the thing I was thinking of, but couldn't remember.
There are two types of people in the world: 1) those that can extrapolate from incomplete data.
Developing a language which is the composite of a number of other languages has a good point - it helps explore new forms of syntax and Java really explored teh VM realm a lot more than most languages dared to.
C# was a direct clone of Java, from the syntax to the libraries. What did it really bring to the table that ws new? We already had bytecode compilation with Java before we ever even saw C#. It was, and is, a pointless waste of man hours that could have been better spent improving upon Java - think not on the C# and Java we have today, think instead what we would ALL have is Microsoft had devoted thought and development energy to expanding the Java that was instead of having to build it from scratch first.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
That, aswell as this link-mess is just a result of undergeneralization in the FS.
Under Windows, a file is a collection of bytes without precisely one name.
Under unix a file is a collection of bytes with zero or more names. The difference is significant.
Thus, in Windows, a file can't have two equally valid names. (hardlinks in unix) At best there's "shortcuts" which are sorta like symlinks, only they're implemented as a desktop-hack so they're really more like kdes .desktop-files. Each tool that want to understand shortcuts need to parse and interpret them, they can't just pretend they're files like you can in unix.
Also, this means a file cannot have zero names and still exist, which is what prevents you from deleting open files on Windows. To allow the removal of the one name *MUST* mean to remove the file too (since every file must have precisely one name), and that ain't doable since there's a process with a open filehandle to that file. (not without killing the process or invalidating its filehandle anyway)
Under unix there is no problem: You delete the file, it now has one name less than it used to have. If it used to have only a single name it now has zero names -- which is perfectly fine as far as unix is concerned. It still has one *reference* though, the open filehandle. So the actual blocks on disc aren't freed. That only happens when the *reference-count* of the file falls to zero.
The trick is, under unix the reference-count of a file is a separate thing from the names of a file. A name is a reference to a file, but it's perfectly possible (and normal) to have other kinds of references to a file too. You can try it yourself if you've got two open shells:
This, frankly, has worked since literally the 70ies on unix (if not the 60ies) its mindboggling that MS *still* hasn't managed to get this rigth.
Do you know *anyone* who seriously uses a Windows-computer and *hasn't* had the "you can't delete/move/rename this file because it is in use" ? Didn't think so. Under unix, it just works. And has worked for decades.
To create a symlink (or hardlink) in NTFS you either need to use Unix services for Windows to get a command line, or use the POSIX compatibility engine programatically (just make the same API calls you would in UNIX though random function names will have leading '_'s just to make it difficult).
/D_CRT_NONSTDC_NO_DEPRECATE in the compiler options.
s tID=87401&SiteID=1
You need to
#define _CRT_NONSTDC_NO_DEPRECATE 1
or add a
http://forums.microsoft.com/MSDN/ShowPost.aspx?Po
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
It's because shortcuts are from the Windows 95 shell, which had to work on FAT. Shortcuts can link to things that aren't files too, IIRC. So they're not really anything to do with symlinks.
.lnk file format
/ lnk/shortcut.pdf
And they're only used in the Start Menu, so only the shell supports them.
Someone reverse engineered the
http://mediasrv.ns.ac.yu/extra/fileformat/windows
NTFS supports real hardlinks, but it's only used by POSIX. You can use DeviceIoControls to make them from Win32, and sysinternals has sample code.
Oddly enough in FAT32, the high 4 bits of each FAT entry are reserved. The problem with a FAT based filesystem is that you don't have an inode to hold a count of the number of links to a file. But you could use the high bits of the fat entry to track it. It'd be kind of gross though, presumably files with more than 16 links would need to add extra clusters to hold the extra counter bits. E.g. a one cluster file would have 4 bits of link count, a two cluster file would have 8 bits and so on. Would be hairy trying to update it though, since you'd need to have some kind of mutex to protect the FAT.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
how many people could there possible be who import text files from Unix systems
Answer: EVERY SINGLE F**KING ONE OF THE WINDOWS USERS HERE. It may be an unknown mystery to you but we have something called a network here and our Windows machines are able to see and read/write the contents of our Unix disks.
I'd like to know how they managed to add utf-8 support to Notepad, remove that 64K barrier you mentioned, and still not fix the linefeed problem. And why Word and wordpad and VC++ IDE and every single other program I try on Windows has no problem handling bare linefeeds (they may write cr+lf, but I consider failure to read that a Unix problem that should be fixed there).
Also the "standard textbox" displays linefeeds as newlines. It has to, considering you can give it a constant string from in-memory in a C program. What you are talking about is a specialized widget that edits file contents only.
"Subjectively I know more and more people who ditch their Windows machines for Macs or even Linux."
Me too, actually.. almost everyone in my circle of friends had Windows machines at home when i first met them, but now a good portion of them use Macs, with many others planning to get a Mac as their next home computer.
Whoa, settle down there, cowboy! That sentence wasn't done. Continue reading it and you'll discover there are more words at the end which change its meaning!
Yes, lots of us slashdotters use Unix text files. But we're also clever enough to realize that Windows comes with more than one text editor, so we can open them with Wordpad or edit.com if we just need to read them, or download a decent editor if we need to write them too. So I repeat, how many Windows users do you think there are who need to work with Unix text files but are too stupid to figure out how to do it?
They didn't add it to Notepad, they added it to the multiline edit control - Unicode support and the removal of the 64k barrier were some of the improvements made in NT. Linefeeds weren't a priority, presumably because the multiline edit control isn't supposed to be a complete text editor, and it's not difficult for apps to convert line breaks themselves.
Easy: they don't use the standard multiline edit control, they use the rich edit control or their own custom controls.
I think you're mistaken. According to MSDN and the MS developer blogs, you need to use \r\n for a line break, not just \n. See, for one example, the comments here.
Something tells me you aren't a Windows developer.
Visual IRC: Fast. Powerful. Free.
And you need to work on your reading comprehension. The AC incorrectly said, "rm the symlink and you don't erase the file it was linking too [sic] (whereas you would if the link was referencing the same inode)." It is not the case the rm-ing a hardlink will erase the file it was linking to. And what's with the qualification of "if the link was referencing the same inode"? Hard links reference the same inode by definition. listen was correcting AC's misconception of hard links; I don't know how you interpreted the post as having anything to do with symlinks. As you admit yourself, listen is correct: "A hardlink has the behavior you describe."
To be fair, his people might be typical Windows end users who don't particularly know nor care that some of their mapped network drives happen to have Linux behind them.
My first full-time employer (95-96) used hard links as follows:
We had a base package (all programs set no-write/delete), and some clients with a handful of custom mods apiece. So we had a script that created a testing directory for a new client (initially populated with hard links to the base package's programs), and another script that removed a specified hard link and replaced it with a separate writeable copy.
Bingo, each testing directory's disk usage is limited to data plus modified programs, you can tell what's been modified in it by looking at which programs aren't hard links, and the base package can't be hosed except by root.
At my current job, if we need a testing directory at all (a lot of my work is just writing custom reports which is safe to do in production), we tend to keep them on the client's network which we can remote-access at need.
I have yet to work anywhere that uses multiple-programmer teams routinely enough to use formal CVS, though it might be argued that one or two of my employers should have at least given it a hard look.
People want to sit down at their PC and be able to watch their movies, listen to their music and play their games without trawling websites for 2 hours, reading manuals.
A well designed distro will allow the first two of those things. It's going to be a long time before the last one becomes a reality.
LK
"Hi. This is my friend, Jack Shit, and you don't know him." - Lord Kano
Seems like that could be done with symbolic links as well, though.
I suppose it could have been, but are there any advantages? I can think of at least one disadvantage ('ls -l' gets ugly - remember, this couldn't be done at a folder level, due to the need to selectively fork a few files).
> I postulate that Bell Labs Unix provided the groundwork for just about all enterprise filesystems in use today.
.PIF files. A .LNK is pretty much identical in concept to a .PIF, and doesn't really try to be a symlink (cygwin does a pretty good job treating them as such, but cygwin is rather a hack, and its own category). I apologize for the tone -- hopefully last week's vacation has mellowed me out some ... I kind of go in cycles :)
Symlinks might possibly be a Unix invention, but I've read plenty of docs that predate Unix that refer to files and directories. I'm under the impression that Unix simply whittled down the Multics filesystem -- some would say to an elegant core, some would disagree (I sort of sit the fence).
> There's a distinction to be made here... a PIF file is not a "link" in this context.
Precisely. I was trying to say in a very snarky way the same point -- that they're really just a small evolution on
Done with slashdot, done with nerds, getting a life.