DIR /s Command on Mapped Drives

[dcampbe1]

Using the command "dir *. /s /ad" on a local drive gives me expected results.
Using the same command on a mapped drive gives me only the root directory.
However if I include a folder name on that mapped drive, e.g., "dir \steve /s /ad" I do get expected results, i.e., many folders in that subdirectory.

Basically the /s does not work at the root level of a mapped drive, but does work within any of the folders below the root level.

I need someway to get a list of all folder names of a mapped drive. I'm not proficient enough to write a script to drill through all of the root directories one at a time to get those respective folder names and could sure use some help/ideas.

Thanks

[foxidrive]

It should work just fine.

What kind of drive is being mapped? NTFS format?
Is it from a Linux box?

try using just

Code: Select all

dir /s /ad 

[dcampbe1]

It should work just fine.

What kind of drive is being mapped? NTFS format?
Is it from a Linux box?

try using just

Code: Select all

dir /s /ad 

It's an external Seagate 4tB NTFS drive from a Win7 64bit machine. I'm accessing it from a Win10 64-bit box. No matter the combination of DOS commands, I can't get past the root listing of folders/files. Specifying any/every sub-folder works as advertised and lets me drill down with no problem. Directly connected drives present no problem, just the mapped ones.

[foxidrive]

It's an external Seagate 4tB NTFS drive from a Win7 64bit machine. I'm accessing it from a Win10 64-bit box. No matter the combination of DOS commands, I can't get past the root listing of folders/files. Specifying any/every sub-folder works as advertised and lets me drill down with no problem. Directly connected drives present no problem, just the mapped ones.

What do you see in the cmd prompt when you type this command?

try using just

Code: Select all

dir /s /ad 

The command works on a mapped drive and the problem seems to stem from some issue with your particular setup.

Map a different HDD and check that one as a test.

[dcampbe1]

It's an external Seagate 4tB NTFS drive from a Win7 64bit machine. I'm accessing it from a Win10 64-bit box. No matter the combination of DOS commands, I can't get past the root listing of folders/files. Specifying any/every sub-folder works as advertised and lets me drill down with no problem. Directly connected drives present no problem, just the mapped ones.

What do you see in the cmd prompt when you type this command?

try using just

Code: Select all

dir /s /ad 

The command works on a mapped drive and the problem seems to stem from some issue with your particular setup.

Map a different HDD and check that one as a test.

I get proper responses when using any variation of the command against non-mapped (local) drives, but using virtually any variation of the command against any mapped drive displays the folder contents of the root directory only. The only way to get out of the root directory is to specify the command against one of its sub-directories. There's no problem at all once I'm below the root directory.

[foxidrive]

I get proper responses when using any variation of the command against non-mapped (local) drives, but using virtually any variation of the command against any mapped drive displays the folder contents of the root directory only.

We can't diagnose what we can't see: I'm only making that point because there is no problem here and I've never had a problem with a mapped drive in that way.

You could be running a batch script that is doing something odd and I would only ever find out if you posted that code.

But a test you can run is to map the same external drive on another PC.
and also use a different PC to access the current pc and drive.

These tests would help to rule out permission and OS issues.

[foxidrive]

I'm accessing it from a Win10 64-bit box.

Other blokes can test this on Win10 as it's not as OS I've felt the need to tinker with yet.

There have been a number of comments here about peculiarities with Win10.

[dcampbe1]

I get proper responses when using any variation of the command against non-mapped (local) drives, but using virtually any variation of the command against any mapped drive displays the folder contents of the root directory only.

We can't diagnose what we can't see: I'm only making that point because there is no problem here and I've never had a problem with a mapped drive in that way.

You could be running a batch script that is doing something odd and I would only ever find out if you posted that code.

But a test you can run is to map the same external drive on another PC.
and also use a different PC to access the current pc and drive.

These tests would help to rule out permission and OS issues.

I've been doing all this testing from a DOS prompt on my Win10 machine without a script. Using virtually any combination of commands on any drive on that machine produces expected results. Using those same commands on any mapped drive of either of two other Win7 machines locks me into the root level of those drives. The response on any such command is simply a re-display of the root directory. The only way out is to either forget mapped drives altogether; or specify each sub-directory under the root directory. The later option is laborious and tedious and would requires a "for" loop script which I don't understand enough to use.

[foxidrive]

I've been doing all this testing from a DOS prompt on my Win10 machine without a script. Using virtually any combination of commands on any drive on that machine produces expected results. Using those same commands on any mapped drive of either of two other Win7 machines locks me into the root level of those drives. The response on any such command is simply a re-display of the root directory.

Check the permissions.

Do those tests to eliminate the machines too.

[dcampbe1]

The only way out is to either forget mapped drives altogether; or specify each sub-directory under the root directory. The later option is laborious and tedious and would requires a "for" loop script which I don't understand enough to use.

Given this is a Win10 issue, I need to find a Win10 solution (lot's of luck Charlie!) or as I mentioned, get help writing a script that will transverse each root sub-directory individually and perform the "dir *.* /s /ad >> catch.txt" or some such similar command.

[foxidrive]

Given this is a Win10 issue

That's not proven in the way I see this issue, from the information provided.

[dcampbe1]

Given this is a Win10 issue

That's not proven in the way I see this issue, from the information provided.

Other blokes can test this on Win10 as it's not as OS I've felt the need to tinker with yet.

There have been a number of comments here about peculiarities with Win10.

I apologize. I responded to the Win10 issue response you sent earlier but it seems to have found its way to the bit bucket. I intended to say what a great idea that was. It caused me to go to one of the Win7 machines and perform the same commands on it. The results were astonishing. Everything worked as it is supposed to, including a DIR of mapped drives. To me this ruled out every thing except a Win10 issue.

[Squashman]

Give this a try from the cmd prompt.

Code: Select all

for /D /R %G in (*) do echo %G

[dcampbe1]

Give this a try from the cmd prompt.

Code: Select all

for /D /R %G in (*) do echo %G

That's exactly what the doctor ordered -- almost. It does what I want it to but lists literally ever folder on the entire drive. I would like to use the same command with a filter to give me only folders with names containing "BI.$BIRIS".

I know this isn't a fix for whatever problem I have with Win10 but it does the job. I only wish I knew the "for" command as well as the old DOS.

[Squashman]

Give this a try from the cmd prompt.

Code: Select all

for /D /R %G in (*) do echo %G

That's exactly what the doctor ordered -- almost. It does what I want it to but lists literally ever folder on the entire drive. I would like to use the same command with a filter to give me only folders with names containing "BI.$BIRIS".

I know this isn't a fix for whatever problem I have with Win10 but it does the job. I only wish I knew the "for" command as well as the old DOS.

The asterisk is a wild card. It is no different then when you were using *.* with your DIR command.