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

[vefatica]

I want to process every directory on the G drive as in the subject of this post. It simply will not go beyond here:

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?

 

[rconn]

If it's failing on a junction, you can tell DO not to recurse into junctions. Otherwise, there's nothing you can do to continue operation -- a fatal error is a fatal error.

(If it's a specific directory you want to skip, use file exclusions.)

 

[vefatica]

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.

 

[vefatica]

Funny! On my C: drive, it's only fatal on the seventh time! So what's fatal and what's not?

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:\>

 

[vefatica]

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.

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.

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]

I want to process every directory on the G drive as in the subject of this post. It simply will not go beyond here:

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]

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.

 

[vefatica]

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.

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".

 

[rconn]

Then give DO an /I(gnore errors) option, like GLOBAL.

Even if DO somehow managed to ignore & continue after all critical errors, it will still fail to complete a "/S c:\" (as will GLOBAL), because of the aforementioned junction loops.

 

[vefatica]

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

"C:\Windows\winsxs\x86_xnacc.inf_31bf3856ad364e35_6.1.7600.16385_none_b381dfe1d4da7da9"

FOR processes all it can also, without being terminated by errors.

 

[vefatica]

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.

g:\> do f in /s /a:+d /d"g:\4ntv8" * ( echo %@full["%f"]\ )
G:\4ntv8\Plugins\
G:\4ntv8\Plugins\hold\

g:\>

 

[vefatica]

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:

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

stops here (below) without an error message!

<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.

<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.

 

[nikbackm]

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.

 

[vefatica]

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.

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"\

 

[nikbackm]

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".

 

[vefatica]

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!

 

[nikbackm]

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.

 

[rconn]

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:

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.

 

[vefatica]

I just tried it again with the same result. All the logs contain only a BOM.

 

[vefatica]

Hmmm! As I said before, it stops here.

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:

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:

"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?

 

[vefatica]

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).

 

[rconn]

The name has mismatched back quotes; it's not surprising that it fails.

 

[vefatica]

The name has mismatched back quotes; it's not surprising that it fails.

It's a valid name, though. And while I have no great desire to process it, I'd like to be able to process what comes after it (DO, GLOBAL).

 

[rconn]

It's a valid name, though. And while I have no great desire to process it, I'd like to be able to process what comes after it (DO, GLOBAL).

Then turn off quote processing.

 

[vefatica]

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?

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]

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).

 

[vefatica]

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.