An issue I really don't understand and is too long and detailed for this "Title" line...

mathewsdw

I've just run into a situation that I really don't understand. And to fully illustrate it, I will show the (annotated) output of a complete TCC session (run in full Administrative mode under Windows 7, no less!) below. So, to start,

HTML:
   Sat  Dec 3, 2011   5:03:06p

TCC  12.11.76   Windows 7 [Version 6.1.7601]
Registered to Daniel Mathews

[Z:\]CD Work-Area-2011-12-03
As you can readily see, the above is just the start of a new TCC session where the first command is a "CD" into the "Work-Area-2011-12-03" directory.

HTML:
[Z:\Work-Area-2011-12-03]Dir /K /M /H
12/03/2011   6:13             Z-Drive.V2011-03-09.unzip

[Z:\Work-Area-2011-12-03]RD Z-Drive.V2011-03-09.unzip /S /Q
TCC: (Sys) The directory is not empty.
"Z:\Work-Area-2011-12-03\Z-Drive.V2011-03-09.unzip"
Simply, of course, an attempt to delete the "Work-Area-2011-12-03\Z-Drive.V2011-03-09.unzip" directory, and (rather strange, given that the "/Q" flag was specified on the "RD" command) failure of same.

And, please note, the error message is not the usual "TCC: (Sys) The process cannot access the file because it is being used by another process." message.

So, to see if it is possibly a problem related to the attributes of file(s) and/or director(y/ies) in the "Z-Drive.V2011-03-09.unzip" directory (which, as far as I know from previous experience where I have done this many times, the /Q flag should ignore anyway):

HTML:
[Z:\Work-Area-2011-12-03]PDir Z-Drive.V2011-03-09.unzi? /(a fn)
____D_________ Z-Drive.V2011-03-09.unzip

[Z:\Work-Area-2011-12-03]PDir /S Z-Drive.V2011-03-09.unzip /(a fpn)
____D_________ Z:\Work-Area-2011-12-03\Z-Drive.V2011-03-09.unzip\Ampersand Director
y
____D_________ Z:\Work-Area-2011-12-03\Z-Drive.V2011-03-09.unzip\Ampersand Director
y Source
____D_________ Z:\Work-Area-2011-12-03\Z-Drive.V2011-03-09.unzip\Ampersand Director
y\Test Directory 4 With With One & and Another & and & a Third Ampersand A
____D_________ Z:\Work-Area-2011-12-03\Z-Drive.V2011-03-09.unzip\Ampersand Director
y\Test Directory 4 With With One & and Another & and & a Third Ampersand A\Test Dir
ectory 4 With With One & and Another & and & a Third Ampersand 7
____D_________ Z:\Work-Area-2011-12-03\Z-Drive.V2011-03-09.unzip\Ampersand Director
y\Test Directory 4 With With One & and Another & and & a Third Ampersand A\Test Dir
ectory 4 With With One & and Another & and & a Third Ampersand 7\Test Directory 4 W
ith With One & and Another & and & a Third Ampersand R
____D_________ Z:\Work-Area-2011-12-03\Z-Drive.V2011-03-09.unzip\Ampersand Director
y Source\Test Directory 4 With With One & and Another & and & a Third Ampersand A
____D_________ Z:\Work-Area-2011-12-03\Z-Drive.V2011-03-09.unzip\Ampersand Director
y Source\Test Directory 4 With With One & and Another & and & a Third Ampersand A\T
est Directory 4 With With One & and Another & and & a Third Ampersand 7
____D_________ Z:\Work-Area-2011-12-03\Z-Drive.V2011-03-09.unzip\Ampersand Director
y Source\Test Directory 4 With With One & and Another & and & a Third Ampersand A\T
est Directory 4 With With One & and Another & and & a Third Ampersand 7\Test Direct
ory 4 With With One & and Another & and & a Third Ampersand R
As you can see, there are no "Read-Only", "Hidden", or "System" files and/or directories in the "Z-Drive.V2011-03-09.unzip" directory, so it really doesn't matter what the "/Q" flag does re. "Read-Only", "Hidden", and "System" files and/or subdirectories.

So, I then show a directory I created specifically for this posting:

HTML:
[Z:\Work-Area-2011-12-03]Dir /K /M /A /H
12/03/2011  16:40             Test It
12/03/2011   6:13             Z-Drive.V2011-03-09.unzip

[Z:\Work-Area-2011-12-03]PDir /A "Test I?" /(a fpn)
RHS_D_________ Z:\Work-Area-2011-12-03\Test It

[Z:\Work-Area-2011-12-03]PDir /A /S "Test It" /(a fpn)
RHS_D_________ Z:\Work-Area-2011-12-03\Test It\One
RHS_D_________ Z:\Work-Area-2011-12-03\Test It\Three
RHS_D_________ Z:\Work-Area-2011-12-03\Test It\Two
RHSA__________ Z:\Work-Area-2011-12-03\Test It\FileOne
RHSA__________ Z:\Work-Area-2011-12-03\Test It\FileThree
RHSA__________ Z:\Work-Area-2011-12-03\Test It\FileTwo
RHS_D_________ Z:\Work-Area-2011-12-03\Test It\One\One
RHS_D_________ Z:\Work-Area-2011-12-03\Test It\One\Three
RHS_D_________ Z:\Work-Area-2011-12-03\Test It\One\Two
RHSA__________ Z:\Work-Area-2011-12-03\Test It\One\One\FileOneOne
RHSA__________ Z:\Work-Area-2011-12-03\Test It\One\Three\FileOneThree
RHSA__________ Z:\Work-Area-2011-12-03\Test It\One\Two\FileOneTwo
RHS_D_________ Z:\Work-Area-2011-12-03\Test It\Three\One
RHS_D_________ Z:\Work-Area-2011-12-03\Test It\Three\Three
RHS_D_________ Z:\Work-Area-2011-12-03\Test It\Three\Two
RHSA__________ Z:\Work-Area-2011-12-03\Test It\Three\One\FileThreeOne
RHSA__________ Z:\Work-Area-2011-12-03\Test It\Three\Three\FileThreeThree
RHSA__________ Z:\Work-Area-2011-12-03\Test It\Three\Two\FileThreeTwo
RHS_D_________ Z:\Work-Area-2011-12-03\Test It\Two\One
RHS_D_________ Z:\Work-Area-2011-12-03\Test It\Two\Three
RHS_D_________ Z:\Work-Area-2011-12-03\Test It\Two\Two
RHSA__________ Z:\Work-Area-2011-12-03\Test It\Two\One\FileTwoOne
RHSA__________ Z:\Work-Area-2011-12-03\Test It\Two\Three\FileTwoThree
RHSA__________ Z:\Work-Area-2011-12-03\Test It\Two\Two\FileTwoTwo
As you can readily see, said directory ("Test It") is not only "Read-Only", "Hidden", and "System" itself, every file and subdirectory in it is also "Read-Only", "Hidden", and "System".

So I then:

HTML:
[Z:\Work-Area-2011-12-03]RD "Test It" /S /Q

[Z:\Work-Area-2011-12-03]Dir /K /M /A /H
12/03/2011   6:13             Z-Drive.V2011-03-09.unzip

[Z:\Work-Area-2011-12-03]
And the "Test It" subdirectory is obviously totally gone, meaning it is absolutely not an issue related to "attributes".

Now, I don't really know if this has anything at all to do with anything, but the "Z-Drive.V2011-03-09.unzip" directory absolutely does not contain any files (of any kind), and I have absolutely no clue as to why that should make any difference at all (and, frankly, IMHO, it shouldn't).

And I will also acknowledge that the directory contains absolutely nothing but subdirectories with ampersands in their names; this directory was actually (re-)created from the contents of a zip file created on March 3, 2011, quite a long time ago which is why I was "looking into" it to see if I could safely just "delete" it. (I was clearly just "experimenting" with directory names that contain ampersand(s), and, as I have mentioned before, I am very "short" of hard-drive space at the present moment so getting rid of things I no longer really need is a fairly-high priority item for me.)

And, I apologize if the bold and bold italic fonts bother anyone; it is just that I have, to this minute, spent at least two to three hours(excluding the time it is taking me to write this posting) trying to resolve this issue (remember, I am very slow because of my multiple disabilities, and it is that hours not spent on accomplishing what I am actually trying to accomplish are "wasted" hours) with no luck at all so I am currently very frustrated; and I truly hope that the above documentation, which is as complete as I know how to make it, completely illustrates the problem.

(And I am also not going to make any more efforts to delete that directory (and its subdirectories) in the immediate future; I want it readily available to try out any suggestions that anyone has to make about resolving this issue.)

rconn

> [Z:\Work-Area-2011-12-03]RD Z-Drive.V2011-03-09.unzip /S /Q
> TCC: (Sys) The directory is not empty.
> "Z:\Work-Area-2011-12-03\Z-Drive.V2011-03-09.unzip"

The error is coming from Windows, not TCC.

And /Q will not suppress error messages, it just suppresses the prompt if
you use /S.

mathewsdw

The error is coming from Windows, not TCC.

And /Q will not suppress error messages, it just suppresses the prompt if
you use /S.
Thank you Rex, for your amazingly quick response so late on a Saturday night! But you only partially answered the question. I totally understand and believe you when you say that it is not a TCC issue (and since I've never gotten an error message when doing that before, that "distinction" was unknown and therefor totally irrelevant to me), but I get at least the "impression" that you at least have some idea about what Windows is "complaining" about, whereas I don't have a clue. Given that there are no files at all in that directory and no subdirectories in that directory that have any of the "Read-Only", "Hidden", and "System" attributes set, what could Windows possibly be "complaining" about and, even more importantly, what can I do (if anything!) to get rid of that (sub)directory? (I have to admit that it's probably just a bias of some kind that I have, but it is pretty much just as much an issue on my RAM disk as it would be on a real, physical, hard disk. That is because the contents of the RAM disk are automatically saved to a real, physical, hard disk on system shutdown and reloaded on system start up, and the only way I can therefore get rid of that (sub)directory is to either disable the device driver for the RAM disk temporarily or boot up into "safe" mode (where the device driver would presumably not be loaded) and delete the file on the physical hard disk that contains the contents of the RAM disk. And if you are wondering why I use a RAM disk in the first place considering that it is saved to a physical hard disk on shutdown (only on shutdown, but I almost never shutdown and/or reboot this machine; I can go literally weeks (if not months!) without ever doing anything other than "hibernating" this machine) the answer(s) are relatively simple: The file that contains the contents of the RAM disk on the physical hard disk when the system is shut down is a single file that is always the same size (the size of the RAM disk, of course) and there's a very good possibility (I've never looked into this so I don't know for sure) that it's always the same file (i.e., is always located at the same INODE) which almost certainly reduces hard-disk fragmentation, and the RAM disk is, obviously, probably hundreds (if not thousands) of times faster than a physical hard disk (and fragmentation, of course, is absolutely not an issue) which is a really good thing because the hard-drive in this laptop ain't that speedy (although I might be spoiled by having used a RAM disk for so long), and the external hard drive (connected through a USB port) is even slower (a lot slower!!!).)

Steve Fabian

Dave:
Another program, including possibly another instance of TCMD/TCC, may be viewing the problem directory. Or it may be the "CWD" (current working directory) for some program. The old suggestion: terminate all programs, restart TCC, try again.
--
Steve

Fross

Perhaps running "handle.exe" from Sysinternals and searching through the
output might give a clue if something has it in use. Here's a
.

Michael

On Sun, Dec 4, 2011 at 6:01 AM, Steve Fabian <> wrote:

> **
> Dave:
> Another program, including possibly another instance of TCMD/TCC, may be
> viewing the problem directory. Or it may be the "CWD" (current working
> directory) for some program. The old suggestion: terminate all programs,
> restart TCC, try again.
> --
> Steve
>
>

rconn

There's a lot of possibilities for Windows refusing to remove a directory:

1) There's another process whose CWD is the directory you're trying to remove.

2) There's still a file or subdirectory in that directory. (Just because you can't see it doesn't preclude its existence -- for example, another app may have created it but Windows hasn't committed it to the disk yet.)

3) Your file system on the ram disk may be bollixed up.

4) An app may have an open handle to that directory (or something in that directory).

5) Windows itself may be overdue for a reboot.

Without personally inspecting your system and running some tests, I can't begin to guess what the actual problem is. TCC is simply reporting what Windows told it when Windows refused to remove the subdirectory; TCC doesn't have any deeper insight into exactly *why* Windows failed.

I'd strongly urge you to reboot, make sure no other apps are running, and try the RD again. If it still fails, and you're sure there's nothing in the subdirectory, you should raise the issue with your ramdisk provider and/or Microsoft.

Charles Dye

Super Moderator
I'd strongly urge you to reboot, make sure no other apps are running, and try the RD again. If it still fails, and you're sure there's nothing in the subdirectory, you should raise the issue with your ramdisk provider and/or Microsoft.

A CHKDSK /F might not be a bad idea, either.

mathewsdw

A CHKDSK /F might not be a bad idea, either.
Charles, "CHKDSK /F" reports, and I quote, "Windows has checked the file system and found no problems."

But it was a good idea...

mathewsdw

Rex, I would like to make it very clear from the outset that I am not at all upset with your (or anybody else's for that matter) responses to my question; in fact, quite the opposite. I truly thank you for taking the time to respond to my issue; I really appreciate it. But, that having been said, a point-by-point response to your (and other people's) response(s) (And I will warn you in advance, this is quite long):

There's a lot of possibilities for Windows refusing to remove a directory:

1) There's another process whose CWD is the directory you're trying to remove.

Rex, while I absolutely can not totally refute that (more on that a little later), I do find it kind of doubtful for two reasons: 1. The nature and purpose of the directory was such that I consider that to be quite unlikely because there is absolutely no reason that any other program would have any interest in it whatsoever or even know of its very existence since was created by a batch (.btm) file that also a least attempted to delete it when it was done with it (and absolutely none of the several dozen other directories that that batch file had made exist now); and 2. As I indicated in my original posting, the error message is that the directory is not empty, not that it is in-use.

2) There's still a file or subdirectory in that directory. (Just because you can't see it doesn't preclude its existence -- for example, another app may have created it but Windows hasn't committed it to the disk yet.)

Same comment as the previous.

3) Your file system on the ram disk may be bollixed up.

Absolutely possible, of course, although that has never happened before (I've been using some version of this RAM disk software for many years; it is from a company named DATARAM (memory.dataram.com/products-and-services/software/ramdisk) and is free - which is very good for me due to my financial circumstances due to my disabilities. Highly recommended.) (I will note here that due to my bad memory, I had to do a Google search to "come up" with that information, despite the fact that I had done so in just that last day or two. Fortunately Google and/or FireFox show you previous (similar, to start) searches you have made as you start to type in the "search" terms. Sad.)

4) An app may have an open handle to that directory (or something in that directory).

Possible, I suppose, subject to the “facts” mentioned above, and again other than the fact that I am not getting an "in-use" message, I am getting a "not empty" message.

I will also note here (for another person - Michael - that has posted in this thread) that the "Handle" command(s) (I say "command(s)" because this is also true for the "Process Explorer" "Find/Find Handle or DLL..." menu option) do not work at all reliably under Windows 7 (and not only that but the Handle command and Process Explorer typically return different results, and it is not at all uncommon for both programs to return both different and incorrect results) documented by at least one other person the last time I looked at - Problem with the "Handle" command under Windows 7. - Sysinternals Forums) – and there are no indications of if and when they might be fixed because (also on the forum) Microsoft has explicitly stated that said tools are not “supported”, and, because of my bad memory this is a real loss for me; I get the "in use" messages on a regular basis and these programs were, of course, what I used to "clear up" the issue. Now I have nothing.)

5) Windows itself may be overdue for a reboot.

Without personally inspecting your system and running some tests, I can't begin to guess what the actual problem is. TCC is simply reporting what Windows told it when Windows refused to remove the subdirectory; TCC doesn't have any deeper insight into exactly *why* Windows failed.

I'd strongly urge you to reboot, make sure no other apps are running, and try the RD again. If it still fails, and you're sure there's nothing in the subdirectory, you should raise the issue with your ramdisk provider and/or Microsoft.

And the above should make it clear why I, frankly, consider that to be an absolutely last resort.

But thank you!!!

P. S. Charles Dye suggested I run "CHKDSK /F"; I did that and no problems were reported.

nikbackm

Have you tried closing all of your TCC instances and only then tried to remove the directory?

I have noticed that TCC under some conditions keeps an handle open to directories without ever closing them.

You can use e.g. HANDLE.EXE from SysInternals to check if this is the case.

In my case it's this alias which calls the external DIRUSE.EXE which causes TCC to leak a handle.

du=((set tmp_du_hassubdir=0) & (for /D %x in (%@optarg[.,%1]\*) (set tmp_du_hassubdir=1 & leavefor)) & ^
(if %tmp_du_hassubdir% == 1 (diruse /m /* %@optarg[.,%1]) else (diruse /m %@optarg[.,%1])))

epement

This problem is reproducible, and it has nothing to do with the ram drive, too many TCC sessions open, or other memory conditions. It took 10 minutes to try to reproduce the issue. I have Win7 Ultimate, TCC 12.11.76, 76 GB free on NTFS.

<code>
[c:\tmp] > type manydirs.btm
@echo off
mkdir "Z-Drive.V2011-03-09.unzip"
mkdir "Z-Drive.V2011-03-09.unzip\Ampersand Directory"
mkdir "Z-Drive.V2011-03-09.unzip\Ampersand Directory Source"
mkdir "Z-Drive.V2011-03-09.unzip\Ampersand Directory\Test Directory 4 With With One & and Another & and & a Third Ampersand A"
mkdir "Z-Drive.V2011-03-09.unzip\Ampersand Directory\Test Directory 4 With With One & and Another & and & a Third Ampersand A\Test Directory 4 With With One & and Another & and & a Third Ampersand 7"
mkdir "Z-Drive.V2011-03-09.unzip\Ampersand Directory\Test Directory 4 With With One & and Another & and & a Third Ampersand A\Test Directory 4 With With One & and Another & and & a Third Ampersand 7\Test Directory 4 With With One & and Another & and & a Third Ampersand R"
mkdir "Z-Drive.V2011-03-09.unzip\Ampersand Directory Source\Test Directory 4 With With One & and Another & and & a Third Ampersand A"
mkdir "Z-Drive.V2011-03-09.unzip\Ampersand Directory Source\Test Directory 4 With With One & and Another & and & a Third Ampersand A\Test Directory 4 With With One & and Another & and & a Third Ampersand 7"
mkdir "Z-Drive.V2011-03-09.unzip\Ampersand Directory Source\Test Directory 4 With With One & and Another & and & a Third Ampersand A\Test Directory 4 With With One & and Another & and & a Third Ampersand 7\Test Directory 4 With With One & and Another & and & a Third Ampersand R"

[c:\tmp] > manydirs
[c:\tmp] > tree /f Z-Drive.V2011-03-09.unzip
C:\tmp\Z-Drive.V2011-03-09.unzip
├──Ampersand Directory
│ └──Test Directory 4 With With One & and Another & and & a Third Ampersand A
│ └──Test Directory 4 With With One & and Another & and & a Third Ampersand 7
│ └──Test Directory 4 With With One & and Another & and & a Third Ampersand R
└──Ampersand Directory Source
└──Test Directory 4 With With One & and Another & and & a Third Ampersand A
└──Test Directory 4 With With One & and Another & and & a Third Ampersand 7
└──Test Directory 4 With With One & and Another & and & a Third Ampersand R

[c:\tmp] > rd /s /q Z-Drive.V2011-03-09.unzip
TCC: (Sys) The directory is not empty.
"C:\tmp\Z-Drive.V2011-03-09.unzip"</code>

The problem is that the directory names are too long for Windows to handle neatly. I also tried <code>"del /sxyz *.*"</code> and that did not work either.

The Take Command folder explorer is able to delete the folder and its subdirectories (of course), but there is no simple solution for a command-line solution in TCC using DEL or RMDIR. I did not try a for...in...do loop.

I am attaching the batch file "manydirs.btm" for the real experts to reproduce the issue.

Attachments

• manydirs.btm
1.4 KB · Views: 41

samintz

Scott Mintz
I can duplicate this. I ran into a really nasty side-effect too. I
manually CD'ed into each subdirectory and tried renaming each directory. I
replaced the ampersands with underscores to see if that made any
difference. When I got to the third level and typed in my REN command,
all of Windows appeared to lock up. Actually, the mouse was still
partially responsive. It moved every once in a while.

I happened to have ProcessExplorer running on a second screen at the time
and System Commit and Physical Memory appeared to be maxed out. Nothing
worked, so I couldn't validate that though.

That being said, you CAN use the \\?\ prefix to handle paths longer than
260 chars.

del /sexyz \\?\Z-Drive.V2011-03-09.unzip\

-Scott

epement <> wrote on 12/05/2011 11:19:55 AM:

> This problem is reproducible, and it has nothing to do with the ram
> drive, too many TCC sessions open, or other memory conditions. It
> took 10 minutes to try to reproduce the issue. I have Win7 Ultimate,
> TCC 12.11.76, 76 GB free on NTFS.
>
> The problem is that the directory names are too long for Windows to
> handle neatly. I also tried "del /sxyz *.*" and that did not work
either.

>
> The Take Command folder explorer is able to delete the folder and
> its subdirectories (of course), but there is no simple solution for
> a command-line solution in TCC using DEL or RMDIR. I did not try a
> for...in...do loop.
>
> I am attaching the batch file "manydirs.btm" for the real experts to
> reproduce the issue.
>
> Attached to this message is manydirs.btm
>
>

Steve Fabian

From: samintz
| I can duplicate this. I ran into a really nasty side-effect too. I
| manually CD'ed into each subdirectory and tried renaming each directory. I
| replaced the ampersands with underscores to see if that made any
| difference. When I got to the third level and typed in my REN command,
| all of Windows appeared to lock up. Actually, the mouse was still
| partially responsive. It moved every once in a while.
|
| I happened to have ProcessExplorer running on a second screen at the time
| and System Commit and Physical Memory appeared to be maxed out. Nothing
| worked, so I couldn't validate that though.
|
| That being said, you CAN use the \\?\ prefix to handle paths longer than
| 260 chars.
|
| del /sexyz \\?\Z-Drive.V2011-03-09.unzip\

Does this suggest that TCC should check the resulting path length when creating directory entries and warn about it? I know it is an NTFS <-> WinAPI mismatch issue and as such MS' responsibility, but we use TCC exactly to avoid as many MS problems as possible...
(Such as being graphic-centered where most computer objects are not graphic!)
--
Steve

epement

There is a TCC solution to deleting the overly-long directories created by the batch file I posted earlier today (the topic of the original poster):
cd \path\to\Z-directory
for /D /R %f in ( "*" ) do echo rmdir "%f" | sort -r > del_dirs.btm
.\del_dirs
The trick is to delete the longest, most remote directory first.

Eric

samintz

Scott Mintz
AFAIK, that doesn't eliminate the path name too long issue. The solution
I posted earlier is what is required.

del /sexyz \\?\path\to\Z-directory

-Scott

epement <> wrote on 12/05/2011 03:26:13 PM:

> There is a TCC solution to deleting the overly-long directories
> created by the batch file I posted earlier today (the topic of the
> original poster):
> cd \path\to\Z-directory
> for /D /R %f in ( "*" ) do echo rmdir "%f" | sort -r > del_dirs.btm
> .\del_dirs
>

mathewsdw

That being said, you CAN use the \\?\ prefix to handle paths longer than 260 chars.

del /sexyz \\?\Z-Drive.V2011-03-09.unzip\

-Scott
either.
Scott, that was a very good idea (I was dimly aware of "\\?\" prefix for long path names but I had never had occasion to use it before, so, simply put, I entirely forgot about it), but, for whatever (other?) strange reason (please read the "postscript" at the end of this posing before you "jump to any conclusions" here) that did not work at all, either. Specifically:

[Z:\Work-Area-2011-12-03]rd "\\?\Z-Drive.V2011-03-09.unzip"
TCC: (Sys) The filename, directory name, or volume label syntax is incorrect.
"\?\Z"
But because your suggested "solution" absolutely did tell me what the problem was, it also inherently told me what I could do to "work around" the problem:

1. I cd'd as far down as I could (i.e., TCC would not let me "cd" any "lower)
on the Z: drive

2. I then subst'd drive Y: to the directory visible at the end of step 1.

3. I cdd'd to drive Y:

4. I tried to "rd /s /q" the directory shown at the end of step 3, and it failed.

5. I cd'd as far down as I could on drive Y: (again, TCC would not let me cd any "lower) on the Y: drive

6. I then subs't drive X: to the directory visible at the end of step 5.

7. I cdd'd to drive X:

8. I tried to "rd /s /q" the directory shown at the end of step 7, and it succeeded.

9. I cdd'd back to drive Y:

10. I un-subst'd drive X:

11. I then tried to "rd /s /q" the dirctory shown at the end of step 9, and it succeeded.

12. I then cdd'd back to drive Z:

13. I then tried to "rd /s /q" the directory name shown at the end of step 12, and it succeed.

Done!!!!
Thank you very much, Scott!!!

Postscript: I did a number of "experiments" on other directories that I created for just that purpose to try to figure out what was "going on", some names with embedded blanks, some strictly alphabetic, and in no case did the "rd" with the directory name preceded by the "\\?\" work! However, News Flash!!!, I did a few more "experiments" just before I wa going to "hit" the "Submit Reply" button on this posting, and I just figured it out! For the "\\?\" prefix to "work", it must be followed by the full path to the directory, which I was not doing! Kind of obvious in hindsight, however.)