DO dir in /s /a:+d /d"g:\" * ( ... )

May 20, 2008
11,407
99
Syracuse, NY, USA
I want to process every directory on the G drive as in the subject of this post. It simply will not go beyond here:
Code:
v:\> do f in /s /a:+d /d"g:\" * ( echo %@full["%f"]\ )
<snip>
G:\pre10sdk\v8lib\
G:\ProcessMonitor\extracted\
G:\Recuva\lang\
G:\shralias\alt\
G:\shralias\oldok\
TCC: (Sys) Access is denied.
 "G:\System Volume Information\"

v:\>
What can I do about that?
 
May 20, 2008
11,407
99
Syracuse, NY, USA
It's failing on "System Volume Information" which is guaranteed to happen on any NTFS drive. And on the system drive, there are other directories where it will fail similarly. Why do you have to consider it "fatal"? ... big deal, you can't get the attributes of a directory that you really don't care about and that the system doesn't want you in anyway ... so just skip it! Considering it "fatal" makes a very straightforward and useful construction (as in this thread's subject) doomed from the start. And it makes DO (one of TCC's centerpieces, IMHO) look lame.
 
May 20, 2008
11,407
99
Syracuse, NY, USA
Funny! On my C: drive, it's only fatal on the seventh time! So what's fatal and what's not?
Code:
g:\> (do f in /s /a:+d /d"c:\" s* ( echo %@full["%f"] )) > nul
TCC: (Sys) Access is denied.
"C:\$Recycle.Bin\S-1-5-21-1441759175-1591074457-3961414381-500\"
TCC: (Sys) Access is denied.
"C:\ProgramData\Microsoft\Crypto\DSS\MachineKeys\"
TCC: (Sys) Access is denied.
"C:\ProgramData\Microsoft\Crypto\Keys\"
TCC: (Sys) Access is denied.
"C:\ProgramData\Microsoft\DRM\Server\"
TCC: (Sys) Access is denied.
"C:\ProgramData\Microsoft\Network\Downloader\"
TCC: (Sys) Access is denied.
"C:\ProgramData\Microsoft\OfficeSoftwareProtectionPlatform\"
TCC: (Sys) Access is denied.
"C:\Recovery\"

g:\>
 
May 20, 2008
11,407
99
Syracuse, NY, USA
More anomalies. If I don't use the attribute switch (/A) ...

On my G: drive it processes the whole drive and produces no errors. Apparently "System Volume Information" is no problem.
Code:
v:\> (do f in /s /d"g:\" * ( echo %@full["%f"] )) | tail /n3
G:\wmi\EULA_WMI_CODE_CREATOR.rtf
G:\wmi\WMICodeCreator.cs
G:\wmi\WMICodeCreator.exe

v:\>

On my system drive, DO conks out after the second error.
Code:
v:\> (do f in /s /d"c:\" * ( echo %@full["%f"] )) | tail /n3
TCC: (Sys) Access is denied.
 "C:\Windows\CSC\v2.0.6\"
TCC: (Sys) Access is denied.
 "C:\Windows\ModemLogs\"
C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF\Fonts\GlobalSansSerif.CompositeFont
C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF\Fonts\GlobalSerif.CompositeFont
C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF\Fonts\GlobalUserInterface.CompositeFont

v:\>
 

rconn

Administrator
Staff member
May 14, 2008
12,348
150
I want to process every directory on the G drive as in the subject of this post. It simply will not go beyond here:
Code:
v:\> do f in /s /a:+d /d"g:\" * ( echo %@full["%f"]\ )

I presume that you actually meant to use /a:d (directories only), not /a:+d (everything + directories)? Your DO command as-written will display every file on the drive.
 

rconn

Administrator
Staff member
May 14, 2008
12,348
150
It's failing on "System Volume Information" which is guaranteed to happen on any NTFS drive. And on the system drive, there are other directories where it will fail similarly. Why do you have to consider it "fatal"? ... big deal, you can't get the attributes of a directory that you really don't care about and that the system doesn't want you in anyway ... so just skip it! Considering it "fatal" makes a very straightforward and useful construction (as in this thread's subject) doomed from the start. And it makes DO (one of TCC's centerpieces, IMHO) look lame.

Has nothing to do with "System Volume Information".

You need a little more time with Windows 7+ - Microsoft has made it very, very difficult (i.e., almost always disastrous) to attempt to recurse through every directory on the drive. At a minimum, there are several junction loops, a lot of hidden directories, a few "super hidden" directories, and a lot of directories with ACL's that will block almost any access (sometimes all access by anything other than the system user). You're dreaming if you think any app can do an /S-equivalent from the root.
 
May 20, 2008
11,407
99
Syracuse, NY, USA
Has nothing to do with "System Volume Information".

You need a little more time with Windows 7+ - Microsoft has made it very, very difficult (i.e., almost always disastrous) to attempt to recurse through every directory on the drive. At a minimum, there are several junction loops, a lot of hidden directories, a few "super hidden" directories, and a lot of directories with ACL's that will block almost any access (sometimes all access by anything other than the system user). You're dreaming if you think any app can do an /S-equivalent from the root.
Then give DO an /I(gnore errors) option, like GLOBAL. To accomplish the goal in this thread's first post, the following works well enough for me. It gets into all the directories it can and produces no error messages ... and that's all I expect.
Code:
global /i /q echo %@full["%_cwd"]
If you don't want to enhance DO, that's your business. As I said before, DO is one of TCC's best features, and it seems a bit lame.

Afterthought: That ("/I") would be a new feature. I will request it in "Feedback".
 
May 20, 2008
11,407
99
Syracuse, NY, USA
GLOBAL ... fail how? I don't see it failing. It processes my whole C: drive, following links, and in the end reports on every directory it was allowed to enter. It does not terminate prematurely. It winds up in
Code:
"C:\Windows\winsxs\x86_xnacc.inf_31bf3856ad364e35_6.1.7600.16385_none_b381dfe1d4da7da9"

FOR processes all it can also, without being terminated by errors.
 
May 20, 2008
11,407
99
Syracuse, NY, USA
I presume that you actually meant to use /a:d (directories only), not /a:+d (everything + directories)? Your DO command as-written will display every file on the drive.
I don't think that's true (or was ever true). IIRC, "+d" has always acted like "d". See below. I get no files.
Code:
g:\> do f in /s /a:+d /d"g:\4ntv8" * ( echo %@full["%f"]\ )
G:\4ntv8\Plugins\
G:\4ntv8\Plugins\hold\

g:\>
 
May 20, 2008
11,407
99
Syracuse, NY, USA
This is working differently, and better (thanks!). DO spits out "Access denied" errors and continues. EXCEPT ...

On my work computer (much like my home computer, Win7/32) this command:
Code:
do d in /s /a:d /d"c:\" * ( echo %@full["%d"] )
stops here (below) without an error message!
Code:
<snip>
C:\ProgramData\Xerox\PrinterDriver\V5.0
C:\ProgramData\Xerox\PrinterDriver\V5.0\Low
C:\ProgramData\Xerox\PrinterDriver\V5.0\Low\S-1-5-21-770604367-1469031932-445207999-1001
v:\>

The next thing to be processed is "c:\Recovery".

At home I get the expected message(s), and DO continues.
Code:
<snip>
C:\ProgramData\VS\vs10sp1\SetupCache\Graphics\
"C:\ProgramData\Windows Genuine Advantage\Data"\
TCC: (Sys) Access is denied.
"C:\Recovery\"
TCC: (Sys) Access is denied.
"C:\System Volume Information\"
C:\Users\Administrator\
"C:\Users\All Users"\
<snip>

P.S. I'd be glad to look for a set-up difference but I don't know what to look for.
 
May 30, 2008
235
2
P.S. I'd be glad to look for a set-up difference but I don't know what to look for.

You could always see if you have a "System Volume Information" or "Recovery" directory on the work drive and if you can CD into them.
 
May 20, 2008
11,407
99
Syracuse, NY, USA
You could always see if you have a "System Volume Information" or "Recovery" directory on the work drive and if you can CD into them.
I have them on both computers and trying to enter them (on either computer) gives the expected "Acces is denied". Here's the work computer.
Code:
v:\> cdd c:\Recovery\
TCC: (Sys) Access is denied.
 "c:\Recovery\"

v:\> cdd "c:\System Volume Information"\
TCC: (Sys) Access is denied.
 "c:\System Volume Information"\
 
May 30, 2008
235
2
Ok, you're not running as SYSTEM then! :)

Maybe the problem is the command itself. I tested it and got some errors, probably due to lack of quotes.

do d in /s /a:d /d"c:\" * ( echo "%@full["%d"]" )

After I added "" around the echo argument like above, then it completed as expected, i.e. it stopped at "System Volume Information".
 
May 20, 2008
11,407
99
Syracuse, NY, USA
Are you, Niklas, using build 19? The behavior changed. Here, at home, I get "Access denied" messages when appropriate but DO doesn't stop; it processes the whole C: drive. At work, it stops without an error message right before C:\Recovery.

Don't laugh about being SYSTEM. Anything is possible!

upload_2015-6-22_12-4-44.png
 
May 30, 2008
235
2
Are you, Niklas, using build 19? The behavior changed. Here, at home, I get "Access denied" messages when appropriate but DO doesn't stop; it processes the whole C: drive. At work, it stops without an error message right before C:\Recovery.

No, still on an older version myself, I thought this was about generic DO behaviour and not DO in the latest version.

Interesting that it changed, looks you got your wish then for a DO that does not stop on such errors.

Don't laugh about being SYSTEM. Anything is possible!

I know, just didn't think that is something you would want to run as your standard command interpreter. :smile:
 

rconn

Administrator
Staff member
May 14, 2008
12,348
150
This is working differently, and better (thanks!). DO spits out "Access denied" errors and continues. EXCEPT ...

On my work computer (much like my home computer, Win7/32) this command:
Code:
do d in /s /a:d /d"c:\" * ( echo %@full["%d"] )
stops here (below) without an error message!

Not reproducible here. If it just stops without any other message there's probably an exception being thrown -- you might have run out of memory (not unlikely on 32-bit Windows) inside a Windows dll.

Look to see if you have a TCMD.LOG file that might have caught the exception.
 
May 20, 2008
11,407
99
Syracuse, NY, USA
Hmmm! As I said before, it stops here.
Code:
C:\ProgramData\Xerox\PrinterDriver\V5.0\Low
C:\ProgramData\Xerox\PrinterDriver\V5.0\Low\S-1-5-21-770604367-1469031932-445207999-1001
c:\>
That's not IMMEDIATELY before c:\recovery (as I had thought). There are 2 more levels of subdirectories.
The next directory in line is this one:
Code:
c:\programdata\xerox\printerdriver\v5.0\low\s-1-5-21-770604367-1469031932-445207999-1001> d
2015-04-21  12:03  <DIR>  ``as-prq-03.ad.syr.edu`AS-MAT-xer-wc7970-Carn215
Here it is again, path-copied from Explorer:
Code:
"C:\ProgramData\Xerox\PrinterDriver\V5.0\Low\S-1-5-21-770604367-1469031932-445207999-1001\``as-prq-03.ad.syr.edu`AS-MAT-xer-wc7970-Carn215"
That's a peculiar name. Could TCC be choking on it?
 
May 20, 2008
11,407
99
Syracuse, NY, USA
Yup. It's the name of the folder. When I re-created that directory structure at home, the same thing happened; that is, DO /S unceremoniously stopped in the same place.

GLOBAL /I /Q also quits unceremoniously there.

And I can't make the oddly-named directory TCC current directory (CD, CDD, auto).
 
Last edited:
May 20, 2008
11,407
99
Syracuse, NY, USA
Then turn off quote processing.
Hmmm! That works (a bit to my surprise).. Why doesn't "SETDOS /X-7" screw up the interpretation of [] in @FULL[] or screw up the "" protecting LFNs inside @FULL?
Code:
v:\> setdos /x-7 & do f in /s /a:+d /d"v:\programdata" * ( echo %@full["%f"]\ )
V:\ProgramData\Xerox\
V:\ProgramData\Xerox\PrinterDriver\
V:\ProgramData\Xerox\PrinterDriver\V5.0\
V:\ProgramData\Xerox\PrinterDriver\V5.0\Low\
V:\ProgramData\Xerox\PrinterDriver\V5.0\Low\S-1-5-21-770604367-1469031932-445207999-1001\
"V:\ProgramData\Xerox\PrinterDriver\V5.0\Low\S-1-5-21-770604367-1469031932-445207999-1001\``as-prq-03.ad.syr.edu`AS-MAT-xer-
wc7970-Carn215"\
"V:\ProgramData\Xerox\PrinterDriver\V5.0\Low\S-1-5-21-770604367-1469031932-445207999-1001\``as-prq-03.ad.syr.edu`AS-MAT-xer-
wc7970-Carn215\foo"\

In my math department, we used to have a Konica-Minolta printer ... nice machine, especially the user interfaces, both local and remote. It always gave me the feeling "this is a slick product". We wore it out.

Now we have a Xerox, and I get the feeling "this is a sick product". The user interfaces, local, remote, and administrative are what you might call "torturous".

I'll see if the IT folks know anything about this poorly named folder.

That said, it's a valid name and one might expect TCC to handle it seamlessly.
 

rconn

Administrator
Staff member
May 14, 2008
12,348
150
That said, it's a valid name and one might expect TCC to handle it seamlessly.

Sure; if you can get everybody else to agree I'll remove the special meaning & processing for back quotes from the parser.

Otherwise, it's kinda hard to have it work one way most of the time and automagically do something else the one time (in 20 years) you want it to behave differently (while doing something that you don't actually want to do anyway).
 
May 20, 2008
11,407
99
Syracuse, NY, USA
Otherwise, it's kinda hard to have it work one way most of the time and automagically do something else the one time (in 20 years) you want it to behave differently (while doing something that you don't actually want to do anyway).
This whole investigation started with my wanting (really) to process every (possible) directory on a drive. That failed miserably but is much better now (thanks again). I can live with TCC not handling that screwy directory name (though it'd be better if it knew it couldn't handle it and continued). The sad part is that if this ever bites me again, it'll probably be so long from now that I'll have forgotten what caused it and what to do about it.
 
Similar threads
Thread starter Title Forum Replies Date
E Fixed Bug with DIR /Z displaying descriptions Support 8
J Paths shown in DIR /B Support 2
K Fixed Prompt display will be shifted after use dir to display a filename with Chinese. (v25.00.28 x64) Support 18
Jesse Heines How to? How to display picture creation date with dir command Support 6
vefatica WAD DIR.BTM? Support 11
DrusTheAxe DIR reports meaningless SYMLINK information Support 14
C show file description? with dir? Support 8
vefatica DIR /F and streams? Support 7
rps Multi-column DIR /v not displaying all files. Support 5
R How to? Dir specific file search patterns with spaces in the pathnames? Support 6
rps Dir /Nfv -> Alt-F2 Support 2
rps @FILESIZE[....,a] allocated size not matching Dir results Support 8
A TCMD - Dir Command puts out blank lines? Support 16
S Problems with dir command in the debugger Support 5
M TCC incorrect dir output since Windows 1803 Support 6
x13 Problem listing repository files using DIR http(s)://... Support 8
cxxl dir /s works in mysterious ways :( Support 4
vefatica Help nit (FFIND and DIR with /S) Support 0
N Fixed Strange dir behavior Support 6
JohnQSmith Weird DIR output (missing lines) Support 1
C 7zip with date range .vs. filelist created with dir and daterange Support 0
D Towards shared (dir-)history lists Support 3
vefatica WAD DIR /HL still gets names wrong Support 16
vefatica DIR /S /HL? Support 4
H Fixed DIR /G returns wrong sizes Support 2
nickles WAD dir.htm Support 2
vefatica DIR \\.\...? Support 4
M Fixed DIR /S /B1 ignores "/S" Support 5
C tcmd.ini not loading from program dir? Support 5
D Fixed Dir /Nm:n has changed Support 1
rps How to? dir /s unexpected results Support 10
vefatica Update to current install dir? Support 8
cgunhouse Problem with "dir /=" Support 4
T dir /h error in empty directory Support 22
P WAD TC 15.0.1.58 x64 crasches with a simple dir command Support 18
CWBillow dir /4 strange Support 2
samintz WAD DIR /B1 and /X Support 2
nickles dir behaves inconsistently Support 5
vefatica DIR, streams, and wildcards? Support 1
vefatica DIR /: /u ... streams not counted? Support 7
vefatica Documentation DIR /B /S /: Support 2
samintz How to? DIR listing for exact match Support 1
dcantor WAD dir "ftp:// ..." fails in TCC 15 Support 7
T How to? dir/pdir - 2nd level down only Support 7
MikeBaas How to? DIR: supress extensions? Support 5
old coot dir /s dies on my C: drive Support 2
A WAD Dir daterange + multiple path wildcards crashes tcc Support 2
old coot TC DIR command has trouble on my SSD Support 2
M Fixed character set in dir/copy Support 3
C odd behavior of "dir" Support 0

Similar threads