X-Spam-Check-By: sourceware.org Date: Wed, 11 Oct 2006 19:00:28 -0400 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: FAQ ALERT Re: [ANNOUNCEMENT] Updated: vim-7.0.122-1 Message-ID: <20061011230028.GA4545@trixie.casa.cgf.cx> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <014c01c6ed5b$d6a1e9a0$a501a8c0 AT CAM DOT ARTIMI DOT COM> <452D60EC DOT 8AA728B8 AT dessent DOT net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <452D60EC.8AA728B8@dessent.net> User-Agent: Mutt/1.5.11 Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com On Wed, Oct 11, 2006 at 02:23:56PM -0700, Brian Dessent wrote: >Dave Korn wrote: >>>I've tried his test case and Mark is right. When a symlink is created >>>with a win32 path, vim can not create the swapfile. When a symlink is >>>created with POSIX filenames there is no problem. >> >>Well of course not. Cygwin - as a special feature - interprets DOS >>paths. > >Sounds like a good example to add to the list of "using DOS/win32 paths >in Cygwin apps might work but it's by accident." Off the top of my head >we have: > >- devices (e.g. open("com1") appears to work but not if you want to do >ioctls) - "foocommand c:/path/file" will always open the file in binary >mode, even if the mount table says it should be treated as text mode - >"ln -s c:/foo/bar baz" confuses vim and probably other apps that read >links - tar (and probably rsync et al.) interprets a file name with a >colon to be a remote hostname Good point, Brian. If anything qualifies as a FAQ, this certainly does. Joshua, would you be willing to write something up about the philosophy of MS-DOS and Cygwin? Known gotchas would be a good thing to include, even if they were only examples. It would be nice to have something official to point to the next time someone starts running on about how Cygwin is "supposed to work". cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/