From: Salazar, G. P. <ger...@si...> - 2007-01-21 00:38:58
|
Hope this is the correct place to ask my question, if not, I guess it = would be in mingw-msys. =20 Anyway, do symbolic links work? I tried a couple, one local pointing to = a file right on my C: drive, and another to a remote NFS directory. In = both instances, it seems that the "symbolic" link was not symbolic at = all, instead, it seemed to have made a copy of the target...in the case = of the single file, a copy of the file, and in the case of the = directory, a copy of the directory and all of its content. =20 This is rather disturbing to me, since that is not the way it works in = my Solaris or RedHat boxes. =20 Any pointers, explanations would be much appreciated. =20 Germ=E1n =20 |
From: Brian D. <br...@de...> - 2007-01-21 01:03:49
|
> "Salazar, German P21322" wrote: > Hope this is the correct place to ask my question, if not, I guess it > would be in mingw-msys. > > Anyway, do symbolic links work? I tried a couple, one local pointing > to a file right on my C: drive, and another to a remote NFS directory. > In both instances, it seems that the "symbolic" link was not symbolic > at all, instead, it seemed to have made a copy of the target...in the > case of the single file, a copy of the file, and in the case of the > directory, a copy of the directory and all of its content. I'm really not sure what you expect here. If you want symlink emulation, use Cygwin, which fakes symlinks with shortcuts. If you want what Windows provides natively without emulation -- which is the whole point of the MinGW project (thus the "minimalist" in the name) -- then you have to settle for copies as the symlink concept does not exist on Windows. For local NTFS volumes, Windows supports hard links and junctions (aka reparse points.) But neither of these are anything like symbolic links, because they create a fixed mapping between two given files/folders, not a symbolic target name that is evaluated on every access. And they cannot span across volumes. And they don't work for network shares. And they don't work with any version of Windows prior to 2k. And they don't work on FAT32 volumes. As you can see, their usefulness is severely limited and thus the MSYS ln command just creates copies, as that is the only solution that works in all cases. > This is rather disturbing to me, since that is not the way it works in > my Solaris or RedHat boxes. Is it really that disturbing that Windows and POSIX systems are fundamentally very different? Brian |
From: Earnie B. <ea...@us...> - 2007-01-21 04:28:19
|
Quoting Brian Dessent <br...@de...>: >> "Salazar, German P21322" wrote: > >> Hope this is the correct place to ask my question, if not, I guess it >> would be in mingw-msys. >> >> Anyway, do symbolic links work? I tried a couple, one local pointing >> to a file right on my C: drive, and another to a remote NFS directory. >> In both instances, it seems that the "symbolic" link was not symbolic >> at all, instead, it seemed to have made a copy of the target...in the >> case of the single file, a copy of the file, and in the case of the >> directory, a copy of the directory and all of its content. > > I'm really not sure what you expect here. If you want symlink > emulation, use Cygwin, which fakes symlinks with shortcuts. If you want > what Windows provides natively without emulation -- which is the whole > point of the MinGW project (thus the "minimalist" in the name) -- then > you have to settle for copies as the symlink concept does not exist on > Windows. > Currently Cygwin implementation of symlink is not really even close for a native system. It will only confuse the issue. > For local NTFS volumes, Windows supports hard links and junctions (aka > reparse points.) But neither of these are anything like symbolic links, > because they create a fixed mapping between two given files/folders, not > a symbolic target name that is evaluated on every access. And they > cannot span across volumes. And they don't work for network shares. > And they don't work with any version of Windows prior to 2k. And they > don't work on FAT32 volumes. As you can see, their usefulness is > severely limited and thus the MSYS ln command just creates copies, as > that is the only solution that works in all cases. > That all said and is true; however, the newer versions of windows are becoming smarter. The symlink functions could be looked at again to provide the possibility but I don't have time. I took out the Cygwin implementation from MSYS because of the reasons stated by Brian. Do a google for junction from sysinternals which MS now owns as well. It will provide directory level softlinks. And their is something resembling a mount system that will allow you to map a directory on another drive to a directory on a different drive. And Vista comes with something called symbolic links. >> This is rather disturbing to me, since that is not the way it works in >> my Solaris or RedHat boxes. > > Is it really that disturbing that Windows and POSIX systems are > fundamentally very different? Soon one won't know the difference. The commercials that show Mac and PC will eventually have the two of them married with the PC in the wedding gown. ;) Earnie Boyd -- Please post responsibly: * Use text posts instead of html; many list members just trash mail with html. * Do not use multipart mime to send both text and html versions. * Do not top post replies; post inline with the parts you are responding to. * Trim the post replies; remove irrelevant information from the quoted article. * Original posters: ** Provide small complete examples of the problem. ** Provide the full command that produced errors. ** Provide the versions of the software used. |
From: Brian D. <br...@de...> - 2007-01-22 00:09:16
|
Earnie Boyd wrote: > That all said and is true; however, the newer versions of windows are > becoming smarter. The symlink functions could be looked at again to > provide the possibility but I don't have time. Don't waste your time. The ability to use real symlinks was supposedly a feature that Windows Vista was to deliver, but in fact the way it was implemented was not to add it at the kernel/filesystem level where it belongs. Instead it added was added to Windows Explorer, and (from what I can tell from the below article) the symlinks are not even part of the filesystem at all but just some registry key somewhere that lists a bunch of "when the user wants this, really display this" key/value pairs that Explorer reads. Thus, they only work if you are using Explorer, but not if you are just using the standard filesystem API, e.g. CreateFile() / open() or whatnot. And so it is essentially a completely useless feature, since the real power of symbolic links is in allowing to redirect access from one location to another without having to write any special code in the apps that are accessing the files. This ability is lost if applications must have special knowledge of some silly new shell API to access symlink functionality rather than regular filesystem calls. http://neosmart.net/blog/2006/vista-symlinks-revisited/ http://slashdot.org/article.pl?sid=06/11/19/018256 (It is possible that I am misinterpreting what is said in those articles, as they don't seem to be 100% clear on exactly how they are implemented.) Brian |
From: Brian D. <br...@de...> - 2007-01-26 04:10:36
|
Brian Dessent wrote: > http://neosmart.net/blog/2006/vista-symlinks-revisited/ > http://slashdot.org/article.pl?sid=06/11/19/018256 > > (It is possible that I am misinterpreting what is said in those > articles, as they don't seem to be 100% clear on exactly how they are > implemented.) Just to elaborate a little bit, here is another article I just read by Mark Russinovich on the changes in Vista's kernel: http://www.microsoft.com/technet/technetmag/issues/2007/02/VistaKernel/default.aspx The section on symbolic links seems pretty clear that this is *not* a feature of the filesystem itself, but a new API that programs must specifically be coded to know about. Thus, it would appear to indeed by totally useless from the standpoint of supporting something like "ln -s" for MinGW, since native native apps like gcc or ld would not be able to read these symlinks at all without adding additional code to them to use the new APIs. Brian |
From: Erik de C. L. <mle...@me...> - 2007-01-26 07:17:33
|
Brian Dessent wrote: > Just to elaborate a little bit, here is another article I just read by > Mark Russinovich on the changes in Vista's kernel: > > http://www.microsoft.com/technet/technetmag/issues/2007/02/VistaKernel/default.aspx > > The section on symbolic links seems pretty clear that this is *not* a > feature of the filesystem itself, but a new API that programs must > specifically be coded to know about. Translation : "The global village idiots at microsoft have again managed to ignore all the good lessons of UNIX and reimplemented UNIX badly." Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "Why do they protest against France for making it illegal to wear hijabs, but not against Saudi Arabia for making it illegal not to wear them?" -- Irshad Manji http://www.timesonline.co.uk/article/0,,2092-1696968,00.html |