From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 62300 invoked by alias); 25 Oct 2017 15:50:16 -0000 Mailing-List: contact cygwin-apps-help@cygwin.com; run by ezmlm Precedence: bulk Sender: cygwin-apps-owner@cygwin.com List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps@cygwin.com Received: (qmail 62038 invoked by uid 89); 25 Oct 2017 15:50:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.4 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: limerock01.mail.cornell.edu Received: from limerock01.mail.cornell.edu (HELO limerock01.mail.cornell.edu) (128.84.13.241) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 25 Oct 2017 15:50:12 +0000 X-CornellRouted: This message has been Routed already. Received: from authusersmtp.mail.cornell.edu (granite4.serverfarm.cornell.edu [10.16.197.9]) by limerock01.mail.cornell.edu (8.14.4/8.14.4_cu) with ESMTP id v9PFoASV007834 for ; Wed, 25 Oct 2017 11:50:10 -0400 Received: from [10.13.22.3] (65-112-130-194.dia.static.qwest.net [65.112.130.194]) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.14.4/8.12.10) with ESMTP id v9PFo94w025201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 25 Oct 2017 11:50:10 -0400 To: cygwin-apps From: Ken Brown Subject: setup and colons in filenames Message-ID: Date: Wed, 25 Oct 2017 15:50:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Cornell-Gauge: Gauge=X X-PMX-CORNELL-AUTH-RESULTS: dkim-out=none; X-IsSubscribed: yes X-SW-Source: 2017-10/txt/msg00118.txt.bz2 This is a followup to the thread started here: https://cygwin.com/ml/cygwin-patches/2017-q4/msg00012.html Currently setup's parse_filename is not correctly parsing filenames in /etc/setup/installed.db that contain colons, as explained in the above thread. It would be easy to fix this by just ripping out the 'base' function, except for the fact that parse_filename is called by ScanFindVisitor::visitFile. I don't know enough about WIN32_FIND_DATA to know whether the call to 'base' is needed for that use of parse_filename. If so, is it safe to skip all colons in that setting, since we're dealing with Win32 filenames and they don't see the colons in Cygwin filenames? Do we need two versions of parse_filename, one that calls base and one that doesn't? Ken