Unexpected behavior from cygpath command

Unexpected behavior from cygpath command

[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



--
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

Re: Unexpected behavior from cygpath command

[Frank Redeker]

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

Re: Unexpected behavior from cygpath command

[Alfred von Campe]

On Nov 13, 2019, at 2:08, Frank Redeker wrote:

> 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).

Thanks, I think this is very interesting, I did not know that such a setting existed.  It was indeed disabled for my E: drive.  However, after enabling it I still can’t get “cygpath -d" to work as expected.  This setting also doesn’t explain why cygpath returns the correct DOS path when I pass it in a Unix style path instead of a Windows style path.

Alfred
--
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

Re: Unexpected behavior from cygpath command

[Brian Inglis]

On 2019-11-13 11:29, Alfred von Campe wrote:
> On Nov 13, 2019, at 2:08, Frank Redeker wrote:
> 
>> 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).
> 
> Thanks, I think this is very interesting, I did not know that such a setting
>  existed. It was indeed disabled for my E: drive. However, after enabling it 
> I still can’t get “cygpath -d" to work as expected. This setting also doesn’t
> explain why cygpath returns the correct DOS path when I pass it in a Unix
> style path instead of a Windows style path.

I have found that there is something different about cygpath that behaves less
consistently when used between `backquotes` than $(command quotes).

Have you tried forcing short names with -s, --short-name: -ds or -ws to see if
those help? If those don't, try adding -a, --absolute: -ads -aws to see if that
makes a difference.

Check the drive file system from an elevated command prompt, and save the
output, reboot, recheck, compare the output to see if anything differs, and
retest, to see if anything changes:

> fsutil fsinfo drivetype e:
e: - Fixed Drive

> fsutil fsinfo volumeinfo e:
Volume Name : ...
Volume Serial Number : 0x6b8d438
Max Component Length : 255
File System Name : NTFS
Is ReadWrite
Not Thinly-Provisioned
Supports Case-sensitive filenames
Preserves Case of filenames
Supports Unicode in filenames
Preserves & Enforces ACL's
Supports file-based Compression
Supports Disk Quotas
Supports Sparse files
Supports Reparse Points
Returns Handle Close Result Information
Supports POSIX-style Unlink and Rename
Supports Object Identifiers
Supports Encrypted File System
Supports Named Streams
Supports Transactions
Supports Hard Links
Supports Extended Attributes
Supports Open By FileID
Supports USN Journal

> fsutil fsinfo ntfsinfo e:
NTFS Volume Serial Number :        0x80ffb5d906b8d438
NTFS Version   :                   3.1
LFS Version    :                   2.0
Number Sectors :                   0x00000000744bc466
Total Clusters :                   0x000000000e89788c
Free Clusters  :                   0x0000000009817c24
Total Reserved :                   0x0000000000008bf7
Bytes Per Sector  :                512
Bytes Per Physical Sector :        4096
Bytes Per Cluster :                4096
Bytes Per FileRecord Segment    :  1024
Clusters Per FileRecord Segment :  0
Mft Valid Data Length :            0x00000000ef640000
Mft Start Lcn  :                   0x00000000000ad74c
Mft2 Start Lcn :                   0x0000000000000002
Mft Zone Start :                   0x0000000005f1ef40
Mft Zone End   :                   0x0000000005f28fc0
Max Device Trim Extent Count :     0
Max Device Trim Byte Count :       0x0
Max Volume Trim Extent Count :     62
Max Volume Trim Byte Count :       0x40000000
Resource Manager Identifier :      99B60DE5-842F-11E1-98AF-D71846560B56

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

--
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

Re: Unexpected behavior from cygpath command

[Lee]

On 11/13/19, Alfred von Campe wrote:
> On Nov 13, 2019, at 2:08, Frank Redeker wrote:
>
>> 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).
>
> Thanks, I think this is very interesting, I did not know that such a setting
> existed.  It was indeed disabled for my E: drive.  However, after enabling
> it I still can’t get “cygpath -d" to work as expected.

Do the 8.3 names exist?
  dir E:\ /n /x

..wondering if you have to recreate the file names to get “cygpath -d" to work

--
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

Re: Unexpected behavior from cygpath command

[Andrey Repin]

Greetings, Lee!

>>> 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).
>>
>> Thanks, I think this is very interesting, I did not know that such a setting
>> existed.  It was indeed disabled for my E: drive.  However, after enabling
>> it I still can’t get “cygpath -d" to work as expected.

> Do the 8.3 names exist?
>   dir E:\ /n /x

> ..wondering if you have to recreate the file names to get “cygpath -d" to work

Wondering, why anybody would use 8.3 names in XXI century.
I've consciously disabled creation of 8.3 names for all but system volumes on
all systems in my reach, and never had to look back.

But if you absolutely must…

fsutil file setshortname <file> <name>

Do note that such name can be literally anything. This is primary reason I
disable them. To reduce amount of confusion in my daily routine.


-- 
With best regards,
Andrey Repin
Monday, November 18, 2019 0:00:42

Sorry for my terrible english...
--
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