I'd like to request that on windows, if a symlink in a repo is a directory, that it be created as a junction point, aka reparse point. It seems to currently be created as a regular file. I understand that versions of windows prior to Vista did not support file symlinks. But everything from NT2K on supports directory symlinks via junction points. Seems like it shouldn't be that hard to recognize when checking out a symlink that it refers to a directory, in which case it could be created as a junction point. While my preferred platforms is *nix, I teach a class and most folks have windows on their machines. Would be nice if they could reference my examples too ;-> Thanks
AFAIK, junction points behave as unix hardlinks (and actually we use when cloning locally), not symlinks. Also, there is little support in Windows to deal with junction points. I know that Vista/Server 2008 come with a command line utility to create them but I don't think Windows Explorer shows them differently and so forth, while symlinks are more common on unix. Just don't use symlinks if you want portability.
I teach an arduino class. Arduino expects that user installed libraries appear within the subfolder LIBRARIES of the program folder. Arduino libraries are not .a or .so files, but rather a folder containing a .c and corresponding .h file. I have a dozen sketches as part of the class. I'd like to have a half dozen common libraries used by all the sketches. One way to do this is to symlink from Examples/EXAMP1/libraries to Examples/libraries. Ditto EXAMP2 through EXAMPN. If you can suggest a way to do this without symlinks, I'm all ears. Given the arduino IDE's constraints, to share the library I need to put it into a common folder and use symlinks on unix and junctions on windows. "don't use symlinks if you want portability". I want portable symlinks, and junctions provide a reasonable, if not perfect, solution. I don't need a whole lot of support for junctions. Nor do most folks. Once a junction is there, if it just behaves like a junction/link, that's fine. For those who want/need to do more, getting the "junction" command tool is trivial. If I could use a hard link to the folder on unix, and have hg represent that as a junction on XP, that would be just fine with me. BUT, I need to use symlinks, cause unix forbids users creating hard links to folders. For pretty good reasons. Without symlinks, I'll need to copy the target folder to each symlink location. As the target is itself a repository, this isn't easy with hg. Or, I'll need to "wrap" hg and do it myself: run a script to create the junctions, and then add the subfolder to .hgignore. Sure would be nice if hg would do it though ...
I answered a question on SO about symlinks on Windows: http://stackoverflow.com/a/8712267/110204 It turns that Python added support for Windows symlinks in Python 3: http://hg.python.org/cpython/rev/730b728e5aef/ There is a package here that adds support to Python 2.x, maybe we could borrow some code from that: http://pypi.python.org/pypi/jaraco.windows
Please note that symbolic links on Windows Vista and up are not the same as junction points (which are supported on older Windows versions but have a number of oddities).
Btw, I just read[1] that to use symbolic links on Windows you need to have elevated admin privileges. That’s kind of a bummer. [1] http://en.wikipedia.org/wiki/NTFS_symbolic_link#Restrictions
Yep, the elevated privileges thing is a show-stopper. This feature probably won't happen before Microsoft decides to follow Apple and replaces their kernel with Unix. Closing.
I'm hoping you'll reconsider and reopen this. While I've worked around the issue, I continue to use hg, have even gotten my employer to shift to hg, and would much like to see it get better in this area. It turns out the "elevated privileges thing" has trivial solutions. One possibility remains to use junction points. Another is to change the symlink priv level policy in the "local security management policy console". And the simplest is to use "run as". Let the user decide, rather than making it impossible for him.
This will almost certainly never happen. It's taken nearly _40 years_ for Unix development practice around symlinks to become relatively secure and dealing with them safely and efficiently in a tool like Mercurial is _still_ a guru-level task. Failing to do so would mean simply checking out a repository off the net would allow someone to take over your machine. By comparison, both Windows junction points and symlinks are highly experimental toys. Take a look at the "Usage Recommendations" for junction points here: http://support.microsoft.com/kb/205524 These are all code for "omg, don't use these things if you care at all about security!!" Ask again in 10 years when these features are in widespread use and all of the associated security implications are thoroughly understood and documented and all the related exploits in the core OS tools have been patched. In general, Mercurial (like almost all SCMs) is just not interested in supporting LOTS of filesystem features, including: - Unix and Windows ACLs - most of the permission bits - Unix device nodes, pipes, etc - ownership info - file timestamps - sparse files - xattrs - MacOS resource forks or Windows streams - etc. All of these are portability, security, or usage nightmares, if not all three.
Thanks Matt. I love hg and it will do fine without this. Just requires a bit of tweaking on my part to make things work. At least for my personal repos. Though I disagree with you - I write all sorts of code for a living (server, language runtimes, compilers, database, etc), where security is a huge issue so I'm fairly well versed in it - you are writing it and I'm not so I'll stop bugging you about it. But being a geek, I can't help arguing ;-> Feel free to ignore the following. symlinks that are kept strictly within the a repository are really not a security issue. That is, you must block the use of ".." to escape from a repo to an ancestor folder. If symlinks that are kept within a "local tree" are dangerous, can you clue me in. Like I said, I need to worry about security issues and need to learn if I'm wrong. How to deal with symlinks, and hard links, securely has been known for a long long time. Probably at least 20 years, though I'm not sure, it's been a while ;-> (BTW, hard links are 40 years old, symlinks are still old, but significantly newer, if I recall about 28). Essentially, require them to be within the "local tree". Some issues remain in the general case, but these are not relevant to the particular case of source repos. Again, if I'm wrong, I'd love to know about it. I looked at junction points briefly when I first filed the bug. And have just checked the article you reference. The usage recommendations are: - use ACLS to block deletion. Not an issue - do not delete a junction point using a tool that does recursive deletion, you will delete everything. Not an issue, that's the behavior you want in this case. - Use caution applying ACLs or compression. I'm assuming because it will apply to the contents of the junction's target. Not an issue, that's the behavior you want in this case. - Do not create cycles. This is an issue. But Unix has it also (though with hard links, not symlinks). Provided you did not create a cycle on unix, you won't have a cycle on windows. And it's not that hard to deal with. Cycle detection is not that hard. Detect the cycle and refuse to create them, while permitting other symlinks. - junction points are scary, be careful ;-> Totally agree about weirdo filesystem features, like acls, device nodes, etc. But I really want my weirdo filesystem feature, symlinks. Feel free to ignore other peoples ;-> More seriously, symlinks entered the mainstream long, long ago.
--- Bug imported by bugzilla@serpentine.com 2012-05-12 09:02 EDT --- This bug was previously known as _bug_ 1825 at http://mercurial.selenic.com/bts/issue1825