Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@sources.redhat.com Delivered-To: mailing list cygwin@sources.redhat.com Date: Tue, 27 Feb 2001 18:41:18 GMT From: Cliff Hones Message-Id: <200102271841.SAA23696@trillian.uk.aonix.com> To: cygwin@cygwin.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.24363.qmail@web6404.mail.yahoo.com> <20010227104026.B10525@redhat.com> <20010227171730.L4275@cygbert.vinschen.de> <20010227114332.F10689@redhat.com> <20010227184131.A5328@cygbert.vinschen.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