From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 77266 invoked by alias); 13 Nov 2019 07:08:37 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 77259 invoked by uid 89); 13 Nov 2019 07:08:37 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,KHOP_HELO_FCRDNS autolearn=ham version=3.3.1 spammy=campe, Alfred, Campe, WINDOWS X-HELO: proxy.razorcat.com Received: from proxy.razorcat.de (HELO proxy.razorcat.com) (213.23.173.139) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 13 Nov 2019 07:08:35 +0000 Received: from [192.168.0.232] (Mimir.ats-berlin.de [192.168.0.232]) by proxy.razorcat.com (8.13.8+Sun/8.13.7) with ESMTP id xAD78Vxc006584 for ; Wed, 13 Nov 2019 08:08:31 +0100 (CET) Subject: Re: Unexpected behavior from cygpath command To: cygwin@cygwin.com References: <033F0B97-041F-4BE4-916E-FD4361142193@von-campe.com> From: Frank Redeker Message-ID: <6a4a0a99-8de9-5302-49da-1e7fd469867e@razorcat.de> Date: Wed, 13 Nov 2019 07:08:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <033F0B97-041F-4BE4-916E-FD4361142193@von-campe.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-11/txt/msg00058.txt.bz2 Am 12.11.2019 um 23:16 schrieb Alfred von Campe: > I have two almost identical build servers, but cygpath is not behaving as expected on one of them. Here is the output from the “good” build server: > > $ cygpath.exe —version | head -1 > cygpath (cygwin) 2.11.2 > > $ cygpath -d 'E:\Program Files (x86)\IAR Systems' > E:\PROGRA~1\IARSYS~1 > > Cygpath has correctly converted the given path to DOS (8.3) format as expected. Here is the output from the “bad” build server. > > $ cygpath.exe —version | head -1 > cygpath (cygwin) 2.11.1 > > $ cygpath -d 'E:\Program Files (x86)\IAR Systems' > E:\Program Files (x86)\IAR Systems > > Why is cygpath returning the same path passed in? Oh wait, it’s running a slightly older version (2.11.1 vs 2.11.2). Perhaps there was a bug in the earlier version. Let me update the Cygwin installation and try again: > > $ cygpath —version | head -1 > cygpath (cygwin) 3.1.0 > > $ cygpath -d 'E:\Program Files (x86)\IAR Systems' > E:\Program Files (x86)\IAR Systems > > WTF? Why is it still doing this? Can there be a global config setting that affects cygpath’s behavior? Hmm, let me try a different approach: > > $ cygpath -d "$(cygpath -u 'E:\Program Files (x86)\IAR Systems')" > E:\PROGRA~1\IARSYS~1 > > Hey, cygpath can convert to DOS paths on this system after all, just not when it’s given a Windows path. Can anyone explain this behavior? > > Alfred Hello, Alfred, I think on both systems the handling of 8.3 names is configured differently. You can check this with the Window command fsutil. (This command requires elevated permissions) I get the following output on my system. C:\WINDOWS\system32>fsutil 8dot3name query d: The volume state is: 0 (8dot3 name creation is enabled). The registry state is: 2 (Per volume setting - the default). Based on the above settings, 8dot3 name creation is enabled on d: You can also change the handling of 8.3 names using this command. See flsutil 8dot3name help C:\WINDOWS\system32>fsutil 8dot3name help ---- 8DOT3NAME Commands Supported ---- query Query the current setting for the shortname behaviour on the system scan Scan for impacted registry entries set Change the setting that controls the shortname behavior on the system strip Remove the shortnames for all files within a directory Greetings Frank -- 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