Jump to content

Welcome to MSFN Forum
Register now to gain access to all of our features. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more. This message will be removed once you have signed in.
Login to Account Create an Account


Photo

Tip: fix DIR /S to recurse hidden subdirs

- - - - -

  • Please log in to reply
15 replies to this topic

#1
shae

shae

    Member

  • Member
  • PipPip
  • 270 posts
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, 05 September 2012 - 03:38 PM.



How to remove advertisement from MSFN

#2
submix8c

submix8c

    Inconceivable!

  • Patrons
  • 4,278 posts
  • OS:none specified
  • Country: Country Flag
?

/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, 06 September 2012 - 02:16 AM.

Someday the tyrants will be unthroned... Jason "Jay" Chasteen; RIP, bro!

Posted Image


#3
allen2

allen2

    Not really Newbie

  • Member
  • PipPipPipPipPipPipPip
  • 1,812 posts
But at least for windows XP:
Dir /s /a-
Works.
Edit: Even dir /s /a works on XP.

Edited by allen2, 06 September 2012 - 01:11 AM.


#4
jds

jds

    -DOS+

  • Member
  • PipPipPipPip
  • 603 posts
  • OS:98SE
  • Country: Country Flag
Great find, shae!

Joe.

#5
CharlotteTheHarlot

CharlotteTheHarlot

    MSFN Master

  • Member
  • PipPipPipPipPipPipPipPip
  • 2,054 posts
  • OS:none specified
  • Country: Country Flag
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 ...

Spoiler


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, 07 September 2012 - 02:36 PM.

... Let him who hath understanding reckon the Number Of The Beast ...


#6
PROBLEMCHYLD

PROBLEMCHYLD

    The Resurrector for old Windows OS

  • Member
  • PipPipPipPipPipPipPipPip
  • 2,528 posts
  • OS:98SE
  • Country: Country Flag
This means the Win95cmd aka cmd.exe in Sp3 needs to be patch too?

Believe God is the Alpha and Omega.
Believe Jesus Christ died for our sins.
Repent for your sins now or there will be
BLOOD

The Path to God


U98SESP3 03-11-2013


#7
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,387 posts
  • OS:none specified
  • Country: Country Flag

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.
  • COMMAND.COM
  • 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

#8
PROBLEMCHYLD

PROBLEMCHYLD

    The Resurrector for old Windows OS

  • Member
  • PipPipPipPipPipPipPipPip
  • 2,528 posts
  • OS:98SE
  • Country: Country Flag
You are right jaclaz :thumbup The Win95cmd does not have this problem. I was too lazy to test, but I just did it now.

Believe God is the Alpha and Omega.
Believe Jesus Christ died for our sins.
Repent for your sins now or there will be
BLOOD

The Path to God


U98SESP3 03-11-2013


#9
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,387 posts
  • OS:none specified
  • Country: Country Flag

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:
  • is the COMMAND.COM in the various NT affected by this "bug"?
  • does the patch work also on these "later" COMMAND.COM's?
  • 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, 08 September 2012 - 04:19 AM.


#10
CharlotteTheHarlot

CharlotteTheHarlot

    MSFN Master

  • Member
  • PipPipPipPipPipPipPipPip
  • 2,054 posts
  • OS:none specified
  • Country: Country Flag

Questions are:

  • is the COMMAND.COM in the various NT affected by this "bug"?
  • does the patch work also on these "later" COMMAND.COM's?
  • 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 ...
Spoiler

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

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


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, 08 September 2012 - 07:52 AM.

... Let him who hath understanding reckon the Number Of The Beast ...


#11
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,387 posts
  • OS:none specified
  • Country: Country Flag

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.micro...kb/100394/en-us
http://support.micro...kb/101875/en-us

http://www.nthelp.com/40/ansiNT.htm
http://www.windowsne...nsisupport.html

EDIT:
And OT :ph34r: , but not much:
http://support.micro...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.o...ovide/ansi.html


jaclaz

Edited by jaclaz, 08 September 2012 - 08:33 AM.


#12
CharlotteTheHarlot

CharlotteTheHarlot

    MSFN Master

  • Member
  • PipPipPipPipPipPipPipPip
  • 2,054 posts
  • OS:none specified
  • Country: Country Flag

JFYI ;):
http://support.micro...kb/100394/en-us
http://support.micro...kb/101875/en-us

http://www.nthelp.com/40/ansiNT.htm
http://www.windowsne...nsisupport.html

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:

... Let him who hath understanding reckon the Number Of The Beast ...


#13
bphlpt

bphlpt

    MSFN Addict

  • Member
  • PipPipPipPipPipPipPip
  • 1,798 posts
  • OS:none specified
  • Country: Country Flag

( 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.robvander...nsi.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, 09 September 2012 - 10:32 AM.

Posted Image


#14
CharlotteTheHarlot

CharlotteTheHarlot

    MSFN Master

  • Member
  • PipPipPipPipPipPipPipPip
  • 2,054 posts
  • OS:none specified
  • Country: Country Flag

( 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.robvander...nsi.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.

... Let him who hath understanding reckon the Number Of The Beast ...


#15
bphlpt

bphlpt

    MSFN Addict

  • Member
  • PipPipPipPipPipPipPip
  • 1,798 posts
  • OS:none specified
  • Country: Country Flag
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, 08 September 2012 - 07:53 PM.

Posted Image


#16
PROBLEMCHYLD

PROBLEMCHYLD

    The Resurrector for old Windows OS

  • Member
  • PipPipPipPipPipPipPipPip
  • 2,528 posts
  • OS:98SE
  • Country: Country Flag

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.

Believe God is the Alpha and Omega.
Believe Jesus Christ died for our sins.
Repent for your sins now or there will be
BLOOD

The Path to God


U98SESP3 03-11-2013





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users



How to remove advertisement from MSFN