Fixed Strange dir behavior

[Niwotian60]

I'm trying to write a script to delete all of the unnecessary installation subdirectories that steam usually leaves behind after a newly-installed program has completed its setup. Typically, these are found in a subdirectory off of each game's main directory named "_CommonRedist". The bug I'm seeing is that if I run the following command from a higher-level directory:

dir "_CommonRedist" /s​

it lists the contents of every subdirectory named "common" after encountering the first subdirectory actually named "_CommonRedist". For example, in the following hierarchy:

d:\
├ dir1

├ sub1
├ sub2
├ common​

├ dir2

├ sub1
├ sub2
├ _CommonRedist​

├ dir3

├ sub1
├ common​

├ dir4

├ sub1
├ sub2

├ common​

running the above command from d:\ does _not_ list the dir1\common subdirectory, does list the dir2\_CommonRedist subdirectory, and then lists both the dir3\common and dir4\sub2\common subdirectories. I have tried other variations of _CommonRedist even including "*_CommonRedist" and "_CommonRedist*" and none of them display the same behavior. I have been able to recreate this on two different drives that have both been chkdsk'd (to verify that there wasn't some type of directory corruption) and I simply cannot explain what is happening. I have also checked my aliases, environment variables, paths, and junctions to make sure there wasn't a tertiary cause but I am unable to find any reason for this to occur.

Running on TCC 21.00.39 x64 Windows 10 [Version 10.0.15063]

 

[vefatica]

I'm not sure what it is doing, but I'm pretty confident that DIR won't do what you want. I suggest you first find all the directories named "_CommonRedist".

FFIND /s /a:d "d:\_CommonRedist"

Then, you could, for example, see what's in each one, perhaps like this:

 DO x in /P FFIND /s /a:d "d:\_CommonRedist" ( dir /s "%x" )

Here's an example of finding all directories named "hold" on the G: drive and then looking at them (snipped after the first one).

BIG SNIP!

 

[Niwotian60]

Thanks, Vince. I wasn't actually planning on using dir as part of the utility (I'm actually writing the script in python). I was just trying to see how many of these subdirectories and how much space they were eating on my drives and got this behavior. I'm not even sure it isn't a problem on my end but I was hoping maybe it could be repeated elsewhere.

 

[vefatica]

Something like this would have done what you want in TCC V16. In v21 it shows every subdirectory of g:\. I don't know if that's a bug. Here's v16 (snipped a lot).

 

[Niwotian60]

Thanks again, Vince! I'm not trying to figure out how to do what I need (that was never a problem). I'm simply trying to understand why "dir abc /s" would list the contents of the first subdirectory that contains an "abc" element and then list most (but seemingly not all) subdirectories thereafter, even if they are rooted higher in the search chain. Yet "dir abc* /s" produces exactly what I would have expected. I'm not sure if I'm explaining the problem well or not (or maybe I'm just not getting it). In any case, it isn't affecting me, I was just reporting it as a possible bug.

 

[Charles Dye]

Thanks again, Vince! I'm not trying to figure out how to do what I need (that was never a problem). I'm simply trying to understand why "dir abc /s" would list the contents of the first subdirectory that contains an "abc" element and then list most (but seemingly not all) subdirectories thereafter, even if they are rooted higher in the search chain. Yet "dir abc* /s" produces exactly what I would have expected. I'm not sure if I'm explaining the problem well or not (or maybe I'm just not getting it). In any case, it isn't affecting me, I was just reporting it as a possible bug.

DIR ABC should be listing the contents of subdirectories named ABC, not those subdirectory entries themselves. To find the subdirectories themselves, use a wildcard -- as you've found. Adding an asterisk makes it a wildcard mask, of course, but may include more entries which you do not want. A more targeted wildspec would be DIR AB[C]

That matches filenames starting with AB, followed by any character which is a C.

 

[vefatica]

DIR ABC should be listing the contents of subdirectories named ABC, not those subdirectory entries themselves. To find the subdirectories themselves, use a wildcard -- as you've found. Adding an asterisk makes it a wildcard mask, of course, but may include more entries which you do not want. A more targeted wildspec would be DIR AB[C]

That matches filenames starting with AB, followed by any character which is a C.

But with "/S" there's something strange. Below, after processing the first directory named "hold", v21 seems to have forgotten about "hold" and goes on to process every remaining directory on the drive.
[cdoe]
Volume in drive G is APPS Serial number is 004c:2a90

Directory of G:\4ntv8\Pluginsx\hold\*

2017-08-21 23:16 <DIR> .
2017-08-21 23:16 <DIR> ..
2017-08-21 23:16 <DIR> sub1
2010-06-13 16:50 6,656 Affinity.dll
6,656 bytes in 1 file and 3 dirs 8,192 bytes allocated

Directory of G:\4ntv8\Pluginsx\hold\sub1\*

2017-08-21 23:16 <DIR> .
2017-08-21 23:16 <DIR> ..
2017-08-21 23:16 <DIR> sub2
0 bytes in 0 files and 3 dirs

Directory of G:\4ntv8\Pluginsx\hold\sub1\sub2\*

2017-08-21 23:16 <DIR> .
2017-08-21 23:16 <DIR> ..
0 bytes in 0 files and 2 dirs

Total for: G:\4ntv8\Pluginsx\hold\sub1\sub2\*
0 bytes in 0 files and 2 dirs 0 bytes allocated

Total for: G:\4ntv8\Pluginsx\hold\sub1\*
0 bytes in 0 files and 5 dirs 0 bytes allocated

Total for: G:\4ntv8\Pluginsx\hold\*
6,656 bytes in 1 file and 8 dirs 8,192 bytes allocated

Total for: G:\4ntv8\*
6,656 bytes in 1 file and 8 dirs 8,192 bytes allocated

Directory of G:\4sdk17\*

2017-01-04 00:12 <DIR> .
2017-01-04 00:12 <DIR> ..
2015-11-12 17:30 1,688 Commands
2015-11-12 17:30 876 Command_Variables
2015-11-12 17:30 1,839 Internal_Variables
<SNIP>[/code]