bug in DIR

Custom / CUSTOM
April 23, 2010 at 10:06:28
Specs: wxp, 2.401 GHz / 2047 MB
Was writing some code, but I got annoyed with the result of bug as shown below:

C:\Temp>dir *.txt /b
test.txt
test.txte

C:\Temp>

I was doing a check (IF EXIST) and it behaves exactly the same as seen by the DIR command. I am not interested in a file named *.txte when I am asking for another name.

How do you work around this bug ?


See More: bug in DIR

Report •


#1
April 23, 2010 at 11:00:35
findstr will filter it out, with /E:
dir /b *.txt | findstr /i /e ".txt"

Report •

#2
April 23, 2010 at 14:41:02
It's not actually a bug. It's a feature. Honestly ;^)

The reason you get this behaviour is that a file name that exceeds the old MS-DOS 8.3 format actually has two names: a long name (test.txte) and an equivalent short name. The short name is automatically generated (like TEST~1.TXT) whenever you save a file with a long name. You can see these names by typing DIR /X.

So the reason you get test.txte is that its short name matches *.txt.

In fact, it would be a bug if it didn't behave like that. Because you can say TYPE TEST~1.TXT (which also happens to be called test.txte) so the file TEST~1.TXT obviously exists, so you would also expect *.txt to match that file.

If you don't like that, there is a Windows NT operating system setting to turn off short names. I don't remember what it's called but you can google it. Just be aware that you would have trouble running 16-bit DOS applications on file names that don't have short names.


Report •

#3
April 24, 2010 at 03:29:54
It's a bug, because this way there is NO parameter foreseen to allow the DIR command to correctly interpret the wildcard named asked. As you show, you can force the old style to be used (with /X) but not the "new" style.

What the default should be is another discussion, but not even foreseeing the parameter as an option, is a bug. Switching off old-name support on OS level, is a bridge too far ... it will lead to more problems, I am sure.


Report •

Related Solutions

#4
April 24, 2010 at 05:46:21
I agree, it's a bug. However, Microsoft often touts its bugs as features, so I guess the definition depends on who you're asking.

The fix for this bug is to switch to a better OS, i.e., Linux or Mac (which is now a flavor of UNIX).


Report •

#5
April 27, 2010 at 21:17:26
I have a perplexing "dir" issue and I'd like to post here in a fresh thread to see if anyone has any pointers. I'm running Win7, 64-bit. If you are run a (64-bit) command (cmd) session, you can type
c:\> dir C:\Windows\System32\capicom.dll
and get
Directory of C:\Windows\System32
File Not Found

However, if you can get to a 32-bit session (like a perl or Rexx interpreter compiled for 32-bit), you can do something like:
c:\> perl
print -e 'C:\Windows\System32\capicom.dll'
^Z
1
the '1' indicates the file exists!

There are many examples which go both ways, i.e., files also exist to the 64-bit command processor but not to the 32-bit, e.g., C:\Windows\System32\cdd.dll

What up with this? Shouldn't 'dir' simply give me the contents of the disk? What's doing the filtering? Thanks!


Report •

#6
April 27, 2010 at 22:14:02
Amen, brother, I have not had the "pleasure" of 64-bit, and do not look fwd to it. No doubt the bus-width is great, but why do "they" always have to foul things up with nonsense (like, f/e, my favorite peeve from way back: spaces-in-filenames).
just let us get our crapping work done! 99/100ths of the stuff they "enhance" is uttter bosh, (my opinion!).

"The fix for this bug is to switch to a better OS, i.e., Linux or Mac (which is now a flavor of UNIX)."

fish-mon, amen #2!


Report •

#7
April 28, 2010 at 01:13:57
I feel like Response 5 could more be a permission issue. Can you navigate to that directory ?

cd /D "C:\Windows\System32"


Report •

#8
April 28, 2010 at 01:15:38
"The fix for this bug is to switch to a better OS, i.e., Linux or Mac (which is now a flavor of UNIX)."

All decent OS'es are flavours of Unix

And 64-bit on a client is a bit stupid. I hear ppl desperately need 64-bit, and then put 2 gigs of memory, and run only webbrowsers and email clients. Not really why 64-bit was invented. That way you get all the problems, and none of the good stuff. But, you can claim to be up to speed with technology. And, if you are running Windows only, that is just a joke one does not realise.


Report •

#9
April 28, 2010 at 03:32:31
Unfortunately 64-bit Windows appears to be a total mess and full of confusion in this respect.

When Windows first came out, when it was 16-bit, it had the directories C:\Windows (or C:\WIN or whatever you chose to call it) and C:\WIN\SYSTEM.

When 32-bit versions came along, they created C:\Windows\System32 (or C:\WINNT\System32) for all the 32-bit DLLs etc.

So where do you think 64-bit DLLs on 64-bit Windows are? No, actually they're in System32. Aaargh!

Yes, on 64-bit versions of Windows, System32 does not contain any 32-bit EXEs or DLLs. It contains the 64-bit versions. The 32-bit versions are all in \Windows\SysWow64.

So we have:
-a folder with "32" in its name that contains just 64-bit software.
- a folder with "64" in its name that contains just 32-bit software.

If that's not bizarre enough for you, wait for this. If you run 32-bit software, it sees all the files in \Windows\SysWow64 as being in \Windows\System32.


Report •

#10
April 28, 2010 at 06:20:31
tvc: And 64-bit on a client is a bit stupid.
Do you know I was using a 64-bit Sun workstation in the mid 90's? Know what I did with it? I installed an x86 emulator, installed Win 3.11, and played Solitaire. No joke.

klint: If you run 32-bit software, it sees all the files in \Windows\SysWow64 as being in \Windows\System32.
Silly, yes, but UAC pulls similar stunts. (Probably why I don't like it)


Report •

#11
April 28, 2010 at 09:09:19
Thanks to everyone for their comments/suggestions. It turns out that all the differences between 64- and 32-bit command session 'dir' listings were within c:\windows\system32. It also turns out that both sessions can dir the syswow64 subdirectory but the 32-bit version cannot see files intended for the 64-bit version (e.g., C:\Windows\System32\cdd.dll mentioned previously)!

It all goes back to, if I'm running as Administrator, why did it ever enter the realm of possibility for Windows to hide files from me???

tvc (post 8): Indeed I can cd to c:\windows\system32. These commands are being run from a cmd prompt with Administrator privileges.

klint (post 9): Thanks for the excellent clarification!

And klint (post 2) : Thanks again for the explanation about extensions. I also consider it a bug because most end users would be unaware that using a period in the filename would eventually be turned into a 3-char extension. Your explanation is better than I got when I complained to usoft Tech Support (escalated to the development team); their explanation was, and I quote, "You did not see this issue in MS-DOS, because MS-DOS worked very hard at being backwards compatible with CP/M." Progress, people! Now we're not being compatible with anything :-)


Report •

#12
April 28, 2010 at 12:39:07
> klint (post 9): Thanks for the excellent clarification!

Clarification? That was meant to confuse you! I obviously failed...

> "You did not see this issue in MS-DOS, because MS-DOS
> worked very hard at being backwards compatible with CP/M."

There is truth in that.


Report •

#13
April 28, 2010 at 15:03:55
>> "You did not see this issue in MS-DOS, because MS-DOS
>> worked very hard at being backwards compatible with CP/M."

> There is truth in that.

Agreed. It may be Taoist. From the Tao Wikipedia entry, and substituting usoft for Tao: "... the ultimate uselessness of trying to understand or control usoft outright. This is often expressed through yin and yang arguments, where every action creates a counter-action as a natural, unavoidable movement within manifestations of usoft."


Report •

#14
April 29, 2010 at 07:07:14
"usoft Tech Support"

That's one of them self-marinating concepts, like 'jumbo shrimp' or 'extra income'.

klint, yep. Just when you thought it couldn't get any goofier.


=====================================
Helping others achieve escape felicity

M2


Report •

Ask Question