On 24/02/2011 15:19, JMGross wrote: > > > > > ----- Ursprüngliche Nachricht ----- Von: Aaron Spike An: Mike Van > Emmerik Gesendet am: 23 Feb 2011 16:07:29 > >> NTFS only sort-of supports hard links - you can use them, but you >> will quickly confuse other windows programs (including Explorer). >> It's like support for having multiple files in a directory that >> differ only by the letter cases. It's a feature that was put into >> NTFS so that MS could tell businesses "NTFS has support for posix - >> you can easily migrate your UNIX software to Windows NT". As soon >> as businesses got hooked on Windows NT, most of the pretence of >> posix compliance was dropped. > > That's not entirely true. Sure, the implementation is different (it's > NTFS and not EXTx), but the support is there and it does not confuse > anyone. Juse the explorer does not offer a frontend for this. NFTS > also supports real linked folders (not just these pseudo-links) > called junctions, but the only point in WIndows where it is used (and > a frontend is provided) is for linking partitions (or USB devices > etc.) into an existing NTFS folder. >
I would be very sceptical about using a feature that is not understood by the basic OS tools, and that very few third-party developers understand or use. I can't think off-hand of /how/ things could go wrong, but I would have to have a good reason before using hard links on windows. Hard linked folder are just asking for trouble - that's why they are disallowed in *nix (except for the special cases of . and ..). They break the tree structure of the file system, and pave the way to unending loops in the directory structure. Hard links are not even very common on *nix systems (excluding . and .., of course) - soft-links are often a better choice. Hard-links are good for programs with multiple names (busybox being an excellent example), and for snapshot-style backups. But mostly a soft-link is a better choice. However, I'd feel safer using hard links than I would using files which differ only in the case of the letters. > However, there's an excellent explorer extension that implements > context menu support as well as visual feedback and a properties > dialog. It's called "NTFS Link" and does a wonderful job. I use it > all day. No problems in daily use (it can even automatically update > links if you rename the destination folder). The only problem I ever > encountered was when I changed the drive letter of a drive. Then Win7 > had problems when It tried to follow the junctions. > Well, if you find they work for you, then great. I haven't had enough good reason to use them, and I've had enough experience of problems with Windows to be sceptical about using them. Having heard your positive comments, I'm less sceptical now than I was - maybe I'll try them sometime. > >>> I have yet to see the "dreaded cygwin1.dll problem" in practice. >>> You may possibly have to add cyggcc* and NLS dlls if you leave >>> NLS enabled, but that's about it. > >> The "cygwin1.dll" problem applies to a number of other dll's >> included with Cygwin, depending on what the application actually >> uses. > >> The problem occurs when you have more than one cygwin program >> running at a time, and they attempt to use different cygwin1 dll's >> (or other dll's). For most windows programs, it isn't a problem >> that two programs load different versions of the same dll - both >> get loaded, and they are kept separate. You don't get the >> advantage of sharing, but both programs work. Cygwin, for some >> reason (I'm sure it's a good reason - perhaps for implementing >> IPC), will not allow more than one copy of each dll to be loaded at >> a time. This means that if you have a program running with one >> version of cygwin1.dll loaded, and try to start a second program >> with a different version, it will fail. > > It happened for me when isntalling AVR-Studio, whcih also installes > Cygwin. And it' snot only about running two programs at the same > time. Another problem is the linux-like behavior to not look at the > current folder first. > > This way, the cygwin is loaded form the location that was put into > the search path by the program that was installed last (or first, > depending on where the path is added - in front or a tthe end of the > existing one) > I never like installations that modify my PATH - it is selfish behaviour. If I want to be able to run programs directly from then command line without specifying the program's path, then /I/ will set PATH appropriately. But the current AvrTools binaries are an example of the problem - there is no reason for the compiler to use cygwin instead of MinGW. The avr-gcc folk contributed a number of patches to make it easier to compile gcc with MinGW! I gather there are a couple of avr tools that have always been compiled with Cygwin (perhaps Insight?). > If this happens, both programs will always load only one > isntallation, which is not necessarily the one required (because > maybe older). > > Inm case of AVR Studio, it caused mspgcc top always load it way > older cygwin version, which of course lead to a crash. Luckily there > is no problem running AVR studio with the newer release. So after > some manual tweaking things work. If the programs would look in their > local installaiton folder first isntead of only checking the global > search path only, there were no problem and they would find and > execute their own installation rather than a possibly completely > different one. > > I know all the reason why this is done, and they apply perfectly to > Linux, but under Windows, the base philosophy is different and this > way of searching for executables is, well, at least of limited > compatibility. > >>> None of the persons speaking about this "dreaded cygwin1.dll >>> problem" has so far been able to provide me with a reproducible >>> "cygwin1.dll problem" that wasn't in itself an administrative >>> problem, and I have yet to see a situation where I would be >>> required to load two different cygwin1.dll versions at the same >>> time. > >> Well, if by "administrative problem" you mean it can be fixed by >> an appropriate amount of deleting extra cygwin dll's, updating a >> single common copy, getting paths correct, etc., then yes, >> "cygwin1.dll" problems are almost always "administrative" problems. >> But they are still a pain and a waste of time and effort for >> someone who knows what they are doing - and much worse for people >> who don't know what is going on. > > This description 'hits the nail on the head'. And I fully agree. The > problem is, that the average WIndows user is no administrator. He > expects that a program installs and runs and does not conflict with > others. Porting Linux applicaitons to Windows should not mean porting > the need to be a skilled admin from Linux to Windows. > > In case of Cygwin, however, it does. Which isn't a problem for a > skilled admin, but is a problem for an average Windows user. And in > case of mspgcc, the fact that someone is (or want sto become) and MSP > developer does not make him a PC admin. And should not require it. > I agree pretty much entirely with you here. I am working on an msp430 project at the moment that is currently compiled with CCS4. I'm going to be porting it over to msp430-gcc in the very near future, and I want to be able to compile it on windows (though I'll probably do it first on Linux) - to me, that means getting the compiler built with MinGW. ------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
