DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=tQLAegQ9x9hd4VgH
	cbg3de+XJf7NKszWoUmuqDqTRbZ4fBXJNxf0I8oPSf0wCFgR/v/+pZKHufRSdHqe
	1IlpRIsg1APO5bFmZw9YhNkU9BUXVuzTkJiJy7Yxwffw7FbHED6DgAYrbK4e+WM/
	O5JzYRzycbqBkyKAXjTeyvh9H3Q=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Subject: Re: Unexpected behavior from cygpath command
To: cygwin@cygwin.com
References: <033F0B97-041F-4BE4-916E-FD4361142193@von-campe.com>
From: Frank Redeker <f.redeker@razorcat.de>
Message-ID: <6a4a0a99-8de9-5302-49da-1e7fd469867e@razorcat.de>
Date: Wed, 13 Nov 2019 08:08:31 +0100
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

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