* Unexpected behavior from cygpath command @ 2019-11-12 22:16 Alfred von Campe 2019-11-13 7:08 ` Frank Redeker 0 siblings, 1 reply; 6+ messages in thread From: Alfred von Campe @ 2019-11-12 22:16 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Unexpected behavior from cygpath command 2019-11-12 22:16 Unexpected behavior from cygpath command Alfred von Campe @ 2019-11-13 7:08 ` Frank Redeker 2019-11-13 23:29 ` Alfred von Campe 0 siblings, 1 reply; 6+ messages in thread From: Frank Redeker @ 2019-11-13 7:08 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Unexpected behavior from cygpath command 2019-11-13 7:08 ` Frank Redeker @ 2019-11-13 23:29 ` Alfred von Campe 2019-11-14 5:22 ` Brian Inglis 2019-11-14 18:23 ` Lee 0 siblings, 2 replies; 6+ messages in thread From: Alfred von Campe @ 2019-11-13 23:29 UTC (permalink / raw) To: Frank Redeker; +Cc: cygwin 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Unexpected behavior from cygpath command 2019-11-13 23:29 ` Alfred von Campe @ 2019-11-14 5:22 ` Brian Inglis 2019-11-14 18:23 ` Lee 1 sibling, 0 replies; 6+ messages in thread From: Brian Inglis @ 2019-11-14 5:22 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Unexpected behavior from cygpath command 2019-11-13 23:29 ` Alfred von Campe 2019-11-14 5:22 ` Brian Inglis @ 2019-11-14 18:23 ` Lee 2019-11-18 20:59 ` Andrey Repin 1 sibling, 1 reply; 6+ messages in thread From: Lee @ 2019-11-14 18:23 UTC (permalink / raw) To: cygwin; +Cc: Frank Redeker 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Unexpected behavior from cygpath command 2019-11-14 18:23 ` Lee @ 2019-11-18 20:59 ` Andrey Repin 0 siblings, 0 replies; 6+ messages in thread From: Andrey Repin @ 2019-11-18 20:59 UTC (permalink / raw) To: Lee, cygwin 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-11-17 21:05 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-11-12 22:16 Unexpected behavior from cygpath command Alfred von Campe 2019-11-13 7:08 ` Frank Redeker 2019-11-13 23:29 ` Alfred von Campe 2019-11-14 5:22 ` Brian Inglis 2019-11-14 18:23 ` Lee 2019-11-18 20:59 ` Andrey Repin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).