Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Date: Tue, 27 Feb 2001 18:41:18 GMT From: Cliff Hones Message-Id: <200102271841.SAA23696@trillian.uk.aonix.com> To: cygwin AT cygwin DOT com In-reply-to: <20010227184131.A5328@cygbert.vinschen.de> (message from Corinna Vinschen on Tue, 27 Feb 2001 18:41:31 +0100) Subject: Re: New symlinks. References: <20010227064205 DOT 24363 DOT qmail AT web6404 DOT mail DOT yahoo DOT com> <20010227104026 DOT B10525 AT redhat DOT com> <20010227171730 DOT L4275 AT cygbert DOT vinschen DOT de> <20010227114332 DOT F10689 AT redhat DOT com> <20010227184131 DOT A5328 AT cygbert DOT vinschen DOT de> I do like the new symlink implementation, but I do find it ironic that what seems a conceptually neat and simple change manages to generate such a lengthy debate. There is general agreement that Cygwin is attempting to implement an interface as close to Unix as possible, barring efficiency constraints, while still using the underlying Windows file system. It follows that in an empty directory "touch foo; ln -s foo bar; ls; ls -lL" (and equivalent programmatic operations) should *not* show any evidence of a file named bar.lnk, even if a Windows file of that name is used to implement the link. But Cygwin can never succeed in performing this kind of file mapping perfectly; there are already difficulties with mixed-case (no-one expects "touch foo; touch FOO; ls" to be Unix-consistent), and with the treatment of .exe files which unfortunately breaks many makefiles. So maybe we are worrying too much about hiding the implementation. Just a thought - if a Windows directory contains both foo (a plain file) and a foo.lnk shortcut, which should Cygwin open, stat etc. see? Cliff Hones. -- Want to unsubscribe from this list? Check out: http://cygwin.com/ml/#unsubscribe-simple