X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,TW_YG,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org To: cygwin AT cygwin DOT com From: Vadim Zeitlin Subject: Re: Bug with paths containing double slashes after double dot after a mount point Date: Sat, 18 Jun 2011 13:43:47 +0000 (UTC) Lines: 40 Message-ID: References: <4DFBC1D2 DOT 4090207 AT ronin-capital DOT com> <4DFBCCB7 DOT 2080408 AT sbcglobal DOT net> <20110618083139 DOT GL3437 AT calimero DOT vinschen DOT de> <20110618113346 DOT GN3437 AT calimero DOT vinschen DOT de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit User-Agent: Loom/3.14 (http://gmane.org/) X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: 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 Corinna Vinschen cygwin.com> writes: > On Jun 18 11:18, Vadim Zeitlin wrote: > > Corinna Vinschen cygwin.com> writes: > > > > > > Don't use Windows paths, use POSIX paths: > > > > As I wrote in my first message[*], I unfortunately can't avoid using > > Windows paths because the original path comes from "g++ -print-search-dirs" > > output of a MinGW compiler. This explains its format and also the trailing > > slash that I can't easily remove neither because the path is processed by > > libtool. And while in the future I might try switching to Cygwin MinGW > > cross-compiler, this can't be done right now so I'd really like to find > > some way of making Windows paths with "..//" in them work with Cygwin. > > cygpath -pm `some-mingw-g++ -print-search-dirs` Sorry to sound like a broken record but, quoting my first message: "I can't even apply cygpath to convert it because this is all done by libtool.". I.e. it's libtool that calls "g++ -print-search-dirs" and then uses "ls $dir/$libname" for each directory in the returned path. And I can't easily change this, even if I somehow could change libtool (but why should it be changed when its code looks correct?), this is libtool of another project (libxml2) and not of one of my own so really can't do much here. > Other than that, I fixed that in CVS. It's a Win32 path coversion problem > which only occurs if there are multiple backslashes trailing a ".." path > component. Thanks a lot for fixing this! Just out of idle curiosity, why did the problem only manifest itself under Windows 7 and not XP? Looking at http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/path.cc.diff?r1=1.629&r2=1.630&cvsroot=src&f=h and surrounding code I don't see anything obviously platform-specific. Anyhow, the important thing is that it's fixed, thanks again! VZ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple