1

Behold below command and actual feedback. 

C:\Temp\AEAPI> dir apb*.*

 Volume in drive C is XXXXXXXX
 Volume Serial Number is XXXX-XXXX
 Directory of C:\Temp\AEAPI

01/08/2009  07:24             9.693 apex_item007.htm
01/08/2009  07:24             6.176 apex_util078.htm
01/08/2009  07:24             5.673 apex_ui_default008.htm
01/08/2009  07:24             8.414 apex_util016.htm
01/08/2009  07:24             5.817 apex_util031.htm
01/08/2009  07:24             5.883 apex_util004.htm
01/08/2009  07:24            10.399 apex_item012.htm
01/08/2009  07:24             6.082 apex_util087.htm
01/08/2009  07:24             5.077 apex_util066.htm
               9 File(s)         63.214 bytes
               0 Dir(s)  42.216.312.832 bytes free

C:\Temp\AEAPI>

Why is it reporting files that do NOT comply with my search parameters ?

I have done some more testing, and it is also replying wrong results (about the same number of files, but different files) when running any of these:

dir apa*.*   
dir apc*.*   
dir apd*.*   
dir apf*.*

It works correctly (meaning: no files found) when running:

dir apg*.*
dir aph*.*

The correct files are returned when using:

dir ape*.*

The files were initially in another directory in which the behaviour was spotted. I copied that full directory (to C:\temp ) and could reproduce the issue on these files as well. There's no subfolders in this folder. No file in the directory is Hidden or Read-Only

I can't understand why this behaviour is shown ..
The disk is formatted in NTFS, OS is win 7 - 64 bit with all latest updates

LPChip
  • 59,229
  • 10
  • 98
  • 140
tee
  • 21
  • 1
  • 3
  • Tempted to close as duplicate of https://superuser.com/questions/238900/winxp-dir-command-3-and-4-char-extensions-are-the-same/ – the symptoms might slightly differ but the underlying problem is the same. – u1686_grawity May 07 '19 at 13:51
  • That indeed is the issue, but the difference is that the confusion is in the main part of the file name, not the extension. What I read from that thread is that there is no final solution, since if you decide to remove the 8.3 names (bot on the system and in ALL files), Windows may be affected because some basic functions still work in 16 bit, and these would fail. Thus, Windows would fail. I'm willing to have a test, but I need a system that I can destroy. Alternatively, why doesn't have the DIR command a parameter to only show the "new style" name ? It has one to force the old one ( /X ) – tee May 08 '19 at 08:17

1 Answers1

0

As in the linked thread, your problem is that the wildcard matches the additional name present on the files – the 8.3 "MS-DOS compatible" name.

Usually the "name" part is shortened by truncating it to 6 characters, then appending ~n with a numeric index (for example, Program Files becomes Progra~1).

However, when the same folder has more than 3 files with identical 6-character prefixes (and the same extension), a different shortening method is used: the first two letters of the name are used, followed by four hexadecimal digits of the filename's CRC hash/checksum, followed by the ~n suffix. This ensures that the initial 6-character prefixes are spread somewhat evenly.

So when you run dir apc*.*, that's two letters of the filename ("ap") and one digit of the CRC hash (hexadecimal digits are 0–9 A–F).

(Side note: "New-style" filenames no longer have a name/extension division, so it is enough to use dir apc*. When Windows sees .* at the end of a wildcard, it is simply ignored.)

What I read from that thread is that there is no final solution, since if you decide to remove the 8.3 names (bot on the system and in ALL files), Windows may be affected because some basic functions still work in 16 bit, and these would fail.

That hasn't been true for nearly two decades – Windows NT series has always been a fully 32-bit system in its core, with the 8.3 feature being there only for obsolete third-party software. (For that matter, the 64-bit amd64/x86_64 variants do not even have the ability to run 16-bit software.)

(I've also heard that recent Windows 10 releases no longer activate 8.3 name generation on new installations by default. Or was it newly formatted disks? Something like that.)

It is nowadays generally safe to strip 8.3 filenames on modern systems, and many guides recommend disabling 8.3 generation to improve the filesystem performance (especially on million-file folders). As a first step, you can disable just the future generation of such filenames and strip only C:\Temp\AEAPI, but keep the existing short names of all system files.

Alternatively you could move the "AEAPI" folder to a separate volume (disk partition) and disable 8.3 name generation only for that volume without risking the system volume in any way.

Alternatively, why doesn't have the DIR command a parameter to only show the "new style" name ? It has one to force the old one ( /X )

That's what it does by default. A regular dir only shows the "new style" names.

The problem isn't with what it shows, but with what it finds. The command does not filter names itself; instead it asks the OS to find all names matching the wildcard. Because the additional 8.3 names have to work while opening a file, they have to work in all other operations, FindFirstFile/FindNextFile included.

There might be an opt-out flag some, but I suspect it would be process-wide rather than settable for individual operations.

u1686_grawity
  • 426,297
  • 64
  • 894
  • 966
  • I used the wrong wording in the last remark, I meant to say to "search" on new names only ... But the /X is not doing that either, it just displays something else, the search is the same. What obviously would be nice is that DIR would have a parameter to search on either full name, or short name, as opposed to both, by default. – tee May 08 '19 at 09:39
  • The 16-bit reference is not necessarily a link to 16-bit programs, as I know they don't run on a 64-bit system. But you state: " but keep the existing short names of all system files." I think that makes sense, but it is an indication that something is still using them. It doesn't really matter what, but that'll prevent to remove all short names, both from the system, as from the files themselves, including system files. – tee May 08 '19 at 09:52
  • 1
    It is **not** an indication that something is still using them. (Just like having things in your attic isn't an indication that you're using them.) It is merely an indication that Windows enables 8.3 name generation when freshly installed, *just in case* the user will want to use 16-bit software – and this name generation applies equally to all types of files, whether they need it or not. – u1686_grawity May 08 '19 at 10:04