shae

Tip: fix DIR /S to recurse hidden subdirs

16 posts in this topic

I just found out "dir /s /a" will not recurse hidden subdirectories. I don't know how I missed it until now. Maybe because hidden dirs just aren't very common. I looked for a solution and found the obscurely named DOS FIX utility, that patches COMMAND.COM to fix it. It's appears to be a generic patcher, and works for Win98SE even though it's not mentioned in the docs.

It changes the flags passed to DOS's FindFirst and FirstNext functions. For Win98SE the patched bytes are at offsets 0xA2B2 and 0xA2BE. In both cases the byte 0x10 (directories) is changed to 0x16 (directories, system, hidden).

Edited by shae
0

Share this post


Link to post
Share on other sites

?

/A Displays files with specified attributes.

D Directories R Read-only files

H Hidden files A Files ready for archiving

S System files - Prefix meaning not

e.g. DIR /S /AH

This "bug" must appear in CMD.EXE as well...

edit - see next post - (xp) DIR x:\WINDOWS /s /a /on /p

yields the hidden $HF_MIG$ and subfolders (hidden) and sub-subfolders/files (not hidden).

Edited by submix8c
0

Share this post


Link to post
Share on other sites

But at least for windows XP:

Dir /s /a-

Works.

Edit: Even dir /s /a works on XP.

Edited by allen2
0

Share this post


Link to post
Share on other sites

Great find, shae!

Joe.

0

Share this post


Link to post
Share on other sites

Yeah, this is an old problem with COMMAND.COM. I just downloaded the above linked file for DOS-FIX and can confirm this is identical to the last and only version that I have from this author, John Augustine, dated 1999-05-12, version 1.1.

It is a smart patcher, that sniffs for the necessary byte string in COMMAND.COM and patches them as necessary, just two bytes in total. The two (non-consecutive) bytes each get changed from hex 10 to hex 16.

I did some research on this sometime after WinXP SP2 came out to see if it was still needed. What I found out is that every version of COMMAND.COM from around DOS 5.0 ( Microsoft MS-DOS and IBM PC-DOS ) up until that very day ( Windows XP SP2 ) required this patch. ( NOTE: I just now checked Windows XP SP3 and found that the file wasn't updated from SP2.)

I never did get around to checking the COMMAND.COM that comes with 32-bit versions of Vista/7 but I will bet they also require it. So I believe it is safe to say that every version of COMMAND.COM from around DOS 5.0 ( Microsoft MS-DOS and IBM PC-DOS ) up until the present day requires this patch.

Here is the DOC file from the DOS-FIX v1.1 distribution ...

Dos Fix V1.1

by John Augustine

DF (Dos Fix) was written in Assembly for MS Dos systems.

A "bug" in MS-Dos's "COMMAND.COM" prevents you from searching hidden

directories for a file/s. Example: If you use the command (without quotes)

"DIR/S *.INI" to locate all ".INI" files in the current directory, including

"all" sub-directories to the current directory (directory you are in), if

there is a hidden sub-directory/s, it/they will be bypassed. Note: Hidden

sub-directories are common in the "WINDOWS" (95/98) directory.

The directory "search" bug involves not setting the proper attribute to

include hidden directories! It is possible that this "bug" was intentional,

allowing users to hide files in a hidden directory?

IMPORTANT NOTE:

You MUST "fix" every "COMMAND.COM" in the hard drive/disk, otherwise, it is

possible to get a system halt with the "invalid command.com" message. All the

"COMMAND.COM" files must match. Sometimes, when you exit certain

applications, the checksum of the "transient" portion of Command.com (the part

of Command.com that was relocated in high memory) will not match because the

application used that upper memory. Therefore, "COMMAND.COM" must be

reloaded. If the checksum still doesn't match, then the system halt occurs

and the error message appears. The checksum is created during startup of the

computer and remains unmodified. Another way of looking at it, the first

"COMMAND.COM" installed when the computer is turned on, becomes the

"reference".

BEFORE AND AFTER TEST, FIRST BEFORE:

At the root directory, type (without quotes) "DIR/S/A *.*" and press Enter.

When finished, write down the total number of files found.

GETTING READY:

If you are a very cautious person (I don't blame you), create an emergency

"Startup" disk ("FORMAT A: /S"), which will contain the original

"COMMAND.COM".

In the hard drive/disk, you must be in the directory where "COMMAND.COM" is

located. There is a minimum of two "COMMAND.COM" files. One is always in the

root directory and one is in the "Windows" (95)(98?) or "DOS" directory on PCs

with Windows 3.1 or Dos only systems.

TIP: I recommend you start at the root directory and type (without quotes)

"DIR/S/P COMMAND.COM" ("/P" will pause when the screen is full) in order to

see which directories have "COMMAND.COM". Make a note of those directories.

FIXING "COMMAND.COM":

1. Starting at the Root directory, simply execute (without quotes) "DOS-FIX"

and press Enter. If "DOS-FIX.EXE" is in a different directory, which does not

have a preset path ("DOS" or "COMMAND" directories), use a path. Example: If

DF is in the "UTYS" directory, type (without quotes) "\UTYS\DOS-FIX".

2. Enter every directory with "COMMAND.COM" and repeat the "DOS-FIX". NOTE:

The original "COMMAND.COM" will be renamed to "COMMAND.BAK".

If you want to verify that the "bug" is fixed, run DF the second time in the

same directory and you will see a message that the bug pattern was not found.

NOTE: If the "bug pattern not found" message occurs the first time you

execute DF, then it may be a Dos version with a different pattern or maybe,

without the bug!

3. Restart your computer after you have fixed all the "COMMAND.COM" files.

AFTER TEST:

Go to the root directory and again type (without quotes) "DIR/S/A *.*" and

see what the total number of files are. Compare that total to what you wrote

down. If you have a PC with Windows 95/98, you will see a noticeable

difference. If you don't see any difference, then your disk (hard drive) does

not have any hidden directories or does not have any files in them. Note:

"/A" specifies all files including hidden and system files.

DIRECTORY WITH THE "SYSTEM" ATTRIBUTE SET:

The fixed "COMMAND.COM" will also "search" a directory with the system

attribute set. There is one sub-directory in the "Windows" (95) directory

with such a setting.

NOTE:

I have fixed "COMMAND.COM" on five computers. Note: Four have Dos 6.2, two

are Dos only PCs, two have Windows 3.1, and one has Dos 7.1 with Windows 95.

If you are using an older or newer version of Dos, I don't know if the bug

pattern is the same. If DF doesn't find the bug pattern, it will let you

know.

FINAL COMMENT:

DF is FREE. Comments or complaints are welcomed. If you use "Snail Mail"

and expect a reply, please include a S.A.S.E.

E-Mail: jaugust@bellatlantic.net

John Augustine N3AOF

3129 Earl St.

Laureldale, Pa 19605

EDIT: as Jaclaz rightly points out below, this DIR display bug that skips certain hidden directories is part of COMMAND.COM, the command interpretor for DOS. It has nothing to do with CMD.EXE which is the NT counterpart.

Edited by CharlotteTheHarlot
0

Share this post


Link to post
Share on other sites

This means the Win95cmd aka cmd.exe in Sp3 needs to be patch too?

0

Share this post


Link to post
Share on other sites

This means the Win95cmd aka cmd.exe in Sp3 needs to be patch too?

No. :no:

IMHO there is some confusion in this topic. :ph34r:

There are TWO command interpreters.

  1. COMMAND.COM
  2. CMD.EXE

CMD.EXE has a slightly different syntax, but AFAIK it worls allright and needs NO patches (at least the "original" one in NT/2K/XP).

In any case this patch is for COMMAND.COM and NOT for *any* CMD:EXE (if you prefer if *any* CMD.EXE is suffering from this or a similar issue this patch won't do anything about it, as it targets COMMAND.COM and NOT CMD.EXE - the "COMMAND.COM" is hardcoded in the DOS-FIX.EXE)

jaclaz

0

Share this post


Link to post
Share on other sites

You are right jaclaz :thumbup The Win95cmd does not have this problem. I was too lazy to test, but I just did it now.

0

Share this post


Link to post
Share on other sites

EDIT: as Jaclaz rightly points out below, this DIR display bug that skips certain hidden directories is part of COMMAND.COM, the command interpretor for DOS. It has nothing to do with CMD.EXE which is the NT counterpart.

Yes and no. :w00t:

CMD.EXE is the DEFAULT command interpreter in NT and later but (at least up to XP/2003, cannot say about Vista :ph34r: and later) there is ALSO COMMAND.COM in the OS.

Using under NT COMMAND.COM instead of CMD.EXE is possible (though mostly senseless).

Questions are:

  1. is the COMMAND.COM in the various NT affected by this "bug"?
  2. does the patch work also on these "later" COMMAND.COM's?
  3. does it make *any* sense, even if it works, to patch something that *noone* ever uses?

OR, we could do a poll:

Raise you hand who has EVER used COMMAND.COM under *any* NT based system, and if yes explain how and why.

jaclaz

Edited by jaclaz
0

Share this post


Link to post
Share on other sites

Questions are:

  1. is the COMMAND.COM in the various NT affected by this "bug"?
  2. does the patch work also on these "later" COMMAND.COM's?
  3. does it make *any* sense, even if it works, to patch something that *noone* ever uses?

OR, we could do a poll:

Raise you hand who has EVER used COMMAND.COM under *any* NT based system, and if yes explain how and why.

I can answer for several of them ( NT versions ) from this computer I am on.

  • Windows 2000 SP4 has COMMAND.COM of size 50,620 bytes and the patch works OK.
  • Windows XP Sp0-Sp1-Sp2-Sp3 ( all have identical COMMAND.COM, but not identical to Win2k ) is also 50,620 bytes and the patch works OK.

The fact that the patcher works only means that the byte string was successfully located and that two bytes were changed from 10 to 16. However this does not mean it was necessary. To determine this an experiment needs to be run. I just did a quick test with a hidden folder on WinXP SP3 and sure enough, the bug is both reproduceable and is corrected by the patch. Follow these steps ...

- go to C:\Temp

- create a subfolder called "Test", make this the current directory.

- copy original COMMAND.COM to "Original.com"

- copy patched COMMAND.COM to "Patched.com"

- create a subfolder called "Visible", copy a file into it.

- copy the subfolder called "Visible" to "Invisible"

- Enable the Hidden attribute for the folder called "Invisible"

The test structure looks like this ...

C:

= Temp

=== Test

----- Original.com

----- Patched.com

===== Visible

------- Readme.txt

===== Invisible <- Hidden Attribute set

------- Readme.txt

Now from within the folder called "Test" open CMD.EXE prompt (rather than pipe the output to file I captured the CMD window to preserve the executed command string.

- execute: DIR /A /S

- execute: ORIGINAL.COM /c DIR /A /S

- execute: PATCHED.COM /c DIR /A /S

Here are the results seen using CMD.EXE ...

C:\Temp\Test>DIR /A /S

Volume in drive C is xxxxxxxxxxx

Volume Serial Number is xxxx-xxxx

Directory of C:\Temp\Test

2012-09-08 09:03 <DIR> .

2012-09-08 09:03 <DIR> ..

2001-08-17 13:32 50,620 Command.com_Winxp(Sp0)(Sp1)(Sp2)(Sp3)_[Original]

2001-08-17 13:32 50,620 Command.com_Winxp(Sp0)(Sp1)(Sp2)(Sp3)_[Patched-Dos-Fix]

2001-08-17 13:32 50,620 Original.com

2001-08-17 13:32 50,620 Patched.com

2012-09-08 08:50 <DIR> Invisible

2012-09-08 08:50 <DIR> Visible

4 File(s) 202,480 bytes

Directory of C:\Temp\Test\Invisible

2012-09-08 08:50 <DIR> .

2012-09-08 08:50 <DIR> ..

2003-07-03 11:53 45 Readme.txt

1 File(s) 45 bytes

Directory of C:\Temp\Test\Visible

2012-09-08 08:50 <DIR> .

2012-09-08 08:50 <DIR> ..

2003-07-03 11:53 45 Readme.txt

1 File(s) 45 bytes

Total Files Listed:

6 File(s) 202,570 bytes

8 Dir(s) 94,182,002,688 bytes free

Here are the results seen using COMMAND.COM unpatched ...

C:\Temp\Test>ORIGINAL.COM /c DIR /A /S

Volume in drive C is xxxxxxxxxxx

Volume Serial Number is xxxx-xxxx

Directory of C:\TEMP\TEST

. <DIR> 09/08/12 7:40a

.. <DIR> 09/08/12 7:40a

COMMAN~1 COM 50620 08/17/01 1:32p

COMMAN~2 COM 50620 08/17/01 1:32p

ORIGINAL COM 50620 08/17/01 1:32p

PATCHED COM 50620 08/17/01 1:32p

INVISI~1 <DIR> 09/08/12 8:05a

VISIBLE <DIR> 09/08/12 8:50a

8 file(s) 202480 bytes

Directory of C:\TEMP\TEST\VISIBLE

. <DIR> 09/08/12 8:05a

.. <DIR> 09/08/12 8:05a

README TXT 45 07/03/03 11:53a

3 file(s) 45 bytes

Total files listed:

11 file(s) 202525 bytes

1023932928 bytes free

Here are the results seen using COMMAND.COM patched ...

C:\Temp\Test>PATCHED.COM /c DIR /A /S

Volume in drive C is xxxxxxxxxxx

Volume Serial Number is xxxx-xxxx

Directory of C:\TEMP\TEST

. <DIR> 09/08/12 7:40a

.. <DIR> 09/08/12 7:40a

COMMAN~1 COM 50620 08/17/01 1:32p

COMMAN~2 COM 50620 08/17/01 1:32p

ORIGINAL COM 50620 08/17/01 1:32p

PATCHED COM 50620 08/17/01 1:32p

INVISI~1 <DIR> 09/08/12 8:05a

VISIBLE <DIR> 09/08/12 8:50a

8 file(s) 202480 bytes

Directory of C:\TEMP\TEST\INVISI~1

. <DIR> 09/08/12 8:05a

.. <DIR> 09/08/12 8:05a

README TXT 45 07/03/03 11:53a

3 file(s) 45 bytes

Directory of C:\TEMP\TEST\VISIBLE

. <DIR> 09/08/12 8:05a

.. <DIR> 09/08/12 8:05a

README TXT 45 07/03/03 11:53a

3 file(s) 45 bytes

Total files listed:

14 file(s) 202570 bytes

1023932928 bytes free

NOTE-1: The unpatched COMMAND.COM does indeed fail to traverse the HIDDEN subfolder, so patching of COMMAND.COM on NT is necessary ( if you intend to ever use it ). This can be seen in the directory output capture. NOTE-2: Several quirks of COMMAND.COM are also visible. Obviously the ~tilde~ laden short file and folder names denote the 8.3 DOS file system convention. We also see that the free space on that HDD as shown by CMD.EXE is over 94 GB but it is shown by COMMAND.COM as 1023932928 bytes free which is 1,023,932,928 bytes or 1 GB. NOTE-3: It is important to remember that DOS-FIX.EXE changes the COMMAND.COM file date/time to current when patching. If you care about preserving the original date/time you will need to 'TOUCH' the file with a utility that can read it from one file and apply it to another. I did do this when I patched COMMAND.COM and this is why in those directory listings you see identical date/time for both files.

To answer Jaclaz's final question, well, that disk size bug and the non-LFN awareness is a huge reason why most people like myself rarely use COMMAND.COM. I was working on some experiments to utilize a parallel batch file interpretor by assigning COMMAND.COM to .BAT and CMD.EXE to .CMD. The idea was to allow perfect reproduction of the way batch files worked on Win9x ( I thought perhaps this was a route to restore ANSI.SYS or ANSI.COM markup as used in our old BAT files ) but it was not fruitful and remains on the back burner. So my answer to "Raise you hand who has EVER used COMMAND.COM under *any* NT based system, and if yes explain how and why." is yes I have, but I have been happier without it. :lol:

EDIT: wording

Edited by CharlotteTheHarlot
0

Share this post


Link to post
Share on other sites

To answer Jaclaz's final question, well, that disk size bug and the non-LFN awareness is a huge reason why most people like myself rarely use COMMAND.COM. I was working on some experiments to utilize a parallel batch file interpretor by assigning COMMAND.COM to .BAT and CMD.EXE to .CMD. The idea was to allow perfect reproduction of the way batch files worked on Win9x ( I thought perhaps this was a route to restore ANSI.SYS or ANSI.COM markup as used in our old BAT files ) but it was not fruitful and remains on the back burner. So my answer to "Raise you hand who has EVER used COMMAND.COM under *any* NT based system, and if yes explain how and why." is yes I have, but I have been happier without it. :lol:

:thumbup

JFYI ;):

http://support.microsoft.com/kb/100394/en-us

http://support.microsoft.com/kb/101875/en-us

http://www.nthelp.com/40/ansiNT.htm

http://www.windowsnetworking.com/kbase/windowstips/windows2000/usertips/miscellaneous/commandinterpreteransisupport.html

EDIT:

And OT :ph34r: , but not much:

http://support.microsoft.com/kb/102901/en-us

So a new question arises:

  • do the above mentioned MS keyb's apply to later than DOS 5.0 versions (and on later NT based OS's)?

EDIT2: Added a couple of links and an almost completely OT one:

http://reboot.pro/10122/

EDIT3: This wasn't an "easy" one, but Hey, I'm still The Finder ;):

http://web.archive.org/web/20071222191504/http://home.tiscali.dk/8x305617/provide/ansi.html

jaclaz

Edited by jaclaz
0

Share this post


Link to post
Share on other sites

Thanks. :thumbup Frustratingly I learned this independently and much to my chagrin that we have the Hobson's choice or more accurately, the Morton's fork of CMD.EXE working nicely but in 2-color, or else using COMMAND.COM with all it's bugs in glorious 16-color BBS beauty. ~sigh~ ( oops, there's those tildes again). Why Microsoft just didn't port the Win9x COMMAND.COM back to WinXP+ is a mystery to me, they broke a huge amount of batch files when the Win9x fork was shut down. I never researched it but I wonder if with enough patching the Win9x version would run in NT. At least LFN would be returned along with ANSI, not to mention being able to launch Windows apps.

Of course if you can just find a link to the official source code to CMD.EXE and COMMAND.COM ( both NT and Win9x ) we can fix it and then recompile the sucker ourselves. :lol:

0

Share this post


Link to post
Share on other sites
( I thought perhaps this was a route to restore ANSI.SYS or ANSI.COM markup as used in our old BAT files )

FWIW, I have used ANSI.COM - http://www.robvanderwoude.com/ansi.php#AnsiCom - to restore the ability to utilize ANSI escape sequences even in Win7. -- (COMMAND.COM was not used)

EDIT: - See my next post below - It ends up that I have not used this particular solution, but www.robvanderwoude.com is very reliable.

Cheers and Regards

Edited by bphlpt
0

Share this post


Link to post
Share on other sites
( I thought perhaps this was a route to restore ANSI.SYS or ANSI.COM markup as used in our old BAT files )

FWIW, I have used ANSI.COM - http://www.robvanderwoude.com/ansi.php#AnsiCom - to restore the ability to utilize ANSI escape sequences even in Win7. -- (COMMAND.COM was not used)

Cheers and Regards

I could swear that I tried the all the ( PCMag ) ANSI.COM variations on WinXP and 7 ( btw, not x64? ). Your post greatly intrigues me. :thumbup

We should probably take this off topic thing elsewhere. Let me know if you have another thread in mind.

0

Share this post


Link to post
Share on other sites

Another option is ANSICON - http://adoxa.3eeweb.com/ansicon/ - and yes there are versions for both x86 and x64. Source is available and it has been updated as recently as June 12, 2012.

EDIT: Sorry for the previous post, this is the one that I personally used, not the previous one. But http://www.robvanderwoude.com hardly ever steers you wrong.

Cheers and Regards

Edited by bphlpt
0

Share this post


Link to post
Share on other sites

It is important to remember that DOS-FIX.EXE changes the COMMAND.COM file date/time to current when patching. If you care about preserving the original date/time you will need to 'TOUCH' the file with a utility that can read it from one file and apply it to another. I did do this when I patched COMMAND.COM and this is why in those directory listings you see identical date/time for both files.

Thanks for the heads up. I prefer for files to have their original timestamp.
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.