Serious DIR Command Bug?

[de Graff]

Can anyone tell me either why the following behavior is NOT considered a
bug, or why Microsoft, in spite of almost yearly postings on the suggestion
site over the last ten years, refuses to fix it?

Please note the entry "2006-02-09 23:30 126,730,752
Weather_5_Thu.bak" which clearly does not contain the string "wed" or even
any occurrance of the letter "d".

You might consider this a trivial complaint, but what if you were piping the
output of the dir command to another process which was supposed to do
something critical? You might end up deleting one or more important files.
If the dir command is using flawed APIs to get the directory listings then
what other processes that use these APIs are also affected?


Z:\SQLBackup>dir *wed* /s
Volume in drive Z is DB5
Volume Serial Number is BC62-4510

Directory of Z:\SQLBackup\adTempus

2006-02-08 20:26 1,447,056,896 adTempus_4_Wed.bak
1 File(s) 1,447,056,896 bytes

Directory of Z:\SQLBackup\distribution

2006-02-08 20:30 19,799,552 distribution_4_Wed.bak
1 File(s) 19,799,552 bytes

Directory of Z:\SQLBackup\Dlygen_Integrated

2006-02-08 20:35 77,875,712 Dlygen_Integrated_4_Wed.bak
1 File(s) 77,875,712 bytes

Directory of Z:\SQLBackup\EMSData

2006-02-08 22:33 253,114,880 EMSData_4_Wed.bak
1 File(s) 253,114,880 bytes

Directory of Z:\SQLBackup\EMS_YYYY_MM

2006-02-08 22:42 485,179,904 EMS_YYYY_MM_4_Wed.bak
1 File(s) 485,179,904 bytes

Directory of Z:\SQLBackup\Interchange_Schedules

2006-02-08 20:40 39,770,624 Interchange_Schedules_4_Wed.bak
1 File(s) 39,770,624 bytes

Directory of Z:\SQLBackup\master

2006-02-08 20:15 80,969,216 master_4_Wed.bak
1 File(s) 80,969,216 bytes

Directory of Z:\SQLBackup\mbh_ddata

2006-02-08 22:39 5,055,398,400 mbh_ddata_4_Wed.bak
1 File(s) 5,055,398,400 bytes

Directory of Z:\SQLBackup\mbh_sdata

2006-02-08 22:35 31,150,592 mbh_sdata_4_Wed.bak
1 File(s) 31,150,592 bytes

Directory of Z:\SQLBackup\model

2006-02-08 20:20 736,768 model_4_Wed.bak
1 File(s) 736,768 bytes

Directory of Z:\SQLBackup\msdb

2006-02-08 20:20 26,629,632 msdb_4_Wed.bak
1 File(s) 26,629,632 bytes

Directory of Z:\SQLBackup\ndAuto

2006-02-08 21:18 2,955,247,104 ndAuto_4_Wed.bak
1 File(s) 2,955,247,104 bytes

Directory of Z:\SQLBackup\ndAutoAnalysis

2006-02-08 21:20 92,349,952 ndAutoAnalysis_4_Wed.bak
1 File(s) 92,349,952 bytes

Directory of Z:\SQLBackup\ndAutoCalendar

2006-02-08 21:25 3,759,616 ndAutoCalendar_4_Wed.bak
1 File(s) 3,759,616 bytes

Directory of Z:\SQLBackup\ndAutoForecast

2006-02-08 21:35 6,423,348,736 ndAutoForecast_4_Wed.bak
1 File(s) 6,423,348,736 bytes

Directory of Z:\SQLBackup\oms_web_requests_archive

2006-02-08 19:45 14,513,664 oms_web_requests_archive_4_Wed.bak
1 File(s) 14,513,664 bytes

Directory of Z:\SQLBackup\OperationOrders

2006-02-08 22:36 511,530,496 OperationOrders_4_Wed.bak
1 File(s) 511,530,496 bytes

Directory of Z:\SQLBackup\Outages

2006-02-08 23:15 51,977,728 Outages_4_Wed.bak
1 File(s) 51,977,728 bytes

Directory of Z:\SQLBackup\RelaySettingSheets

2006-02-08 19:50 6,922,752 RelaySettingSheets_4_Wed.bak
1 File(s) 6,922,752 bytes

Directory of Z:\SQLBackup\Schedules

2006-02-08 23:20 14,501,376 Schedules_4_Wed.bak
1 File(s) 14,501,376 bytes

Directory of Z:\SQLBackup\Ultrasound

2006-02-08 23:25 287,260,160 Ultrasound_4_Wed.bak
1 File(s) 287,260,160 bytes

Directory of Z:\SQLBackup\Weather

2006-02-08 23:30 125,616,640 Weather_4_Wed.bak
2006-02-09 23:30 126,730,752 Weather_5_Thu.bak
2 File(s) 252,347,392 bytes

Directory of Z:\SQLBackup\wpg-apps-40\DovercourtSPS_Config_db

2006-02-08 22:15 23,557,632 DovercourtSPS_Config_db_4_Wed.bak
1 File(s) 23,557,632 bytes

Directory of Z:\SQLBackup\wpg-apps-40\master

2006-02-08 20:00 15,228,416 master_4_Wed.bak
1 File(s) 15,228,416 bytes

Directory of Z:\SQLBackup\wpg-apps-40\model

2006-02-08 20:10 738,816 model_4_Wed.bak
1 File(s) 738,816 bytes

Directory of Z:\SQLBackup\wpg-apps-40\msdb

2006-02-08 20:20 14,704,128 msdb_4_Wed.bak
1 File(s) 14,704,128 bytes

Directory of Z:\SQLBackup\wpg-apps-40\test1_PROF

2006-02-08 22:30 2,180,608 test1_PROF_4_Wed.bak
1 File(s) 2,180,608 bytes

Directory of Z:\SQLBackup\wpg-apps-40\test1_SERV

2006-02-08 22:30 111,539,712 test1_SERV_4_Wed.bak
1 File(s) 111,539,712 bytes

Total Files Listed:
29 File(s) 18,299,390,464 bytes
0 Dir(s) 23,374,270,464 bytes free

Z:\SQLBackup>

 

[jg]

may be it is one those problems that people can not reproduce, and hence no
solution.

Most people will not try to create all the files you have under the
directory you listed but just try a few.

Besides, if you have to manipulate them, you can double check the name
first.
So it may not be a high priority problem.

 

[UnaCoder]

This behavior has been in DOS since......before version 3. Their wild
card selection of file names has been broken since as long as i've been
using computers. I would suggest using BASH for windows

 

[de Graff]

I have to wonder though that if they can't get something so fundamental to
work properly, how are we to take their larger efforts seriously?

 

[M and D]

Considering the number of Windows users worldwide who still use the DIR command, I can see where Microsoft may have set some priorities.

Steven

 

[Gloops]

Hello, I created a file named Weather_5_Thu.bak in my Temp directory,
and from the root "DIR wed" did not point it, whereas DIRCMD=/S /B /P.

I presume some attention should be addressed to the properties of your
files, and to what is present in the directory, in order to understand
what happens. What is the date of creation of the directory ?

Particularly, I should have a look at the short name of the file, at the
different dates (creation, modification, access), verifying the day in
the week. Right that it is no correct explanation, but just a path of
search ...

I presume you launched an anti-virus.

sysinternals.com has a program that finds distorsions between the
different ways a file is addressed. Verify the description, I think it
is RootkitRevealer, as rootkits (a very malicious sort of viruses) are
one of the causes that can make those different indexes to differ.


Until you find what happens with that, you should consider filtering the
results with FIND.

Is there no file with "wed" in the name that was not listed ?

*

I see you use a complete display of DIR to perform a deletion by a
program, did not you consider DIR /B ? Rather more handy to program, no ?

Perhaps you would obtain something usable with
DIR \ /S /B |FIND "wed" >list.txt

After that, your program can use an entire line of list.txt, except the
CR/LF, as a file specification. No need to save the directory from the
line that begins with " Directory of ", nor to detect a line that begins
with a date, and to extract from the 40th character.

I presume it would be easier if the day of week was at the beginning of
the name. The deletion command woud be :
DEL /S /Q \Wed*.*

But perhaps this is not the topic.
______________________________________
de Graff wrote, on 2/16/2006 5:42 PM :

 

[UnaCoder]

That's why I usualy use linux ;-)

I keep a computer with XP around purely for gaming...

 

[de Graff]

But is it the DIR coammand that is flawed or is it the underlying APIs? An
earlier response states that this has been a bug in DOS since before version
3. So how many years exactly is it that MS has had to fix the bug and not
done so? And since this bug predates Windows by a number of years, it also
means that the importance, and therefore the possible damage resulting from
this bug was at one time much greater than it is now (unless the bug also
exists in the APIs).

Whatever the cause of the bug or the reason it still exists,

a) it is an obvious bug
b) it's damned sloppy programming
c) it could be easily fixed
d) it should be fixed

 

[M and D]

Instead of posting in a public newsgroup, you should be bringing your campaign to Microsoft. Get over there right now and pound on those doors. Demand satisfaction. Call Geraldo Rivera and tell him to bring a camera crew. I'll bet those Microsofties will put a team on it before you can say "class action."

Steven

 

[de Graff]

OK. Perhaps I am over-reacting just a tad. But I DID let MS know about the
bug.