Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

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

May
855
0
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

ISO8601 plugin v1.1.1 loaded.
SafeChars plugin v1.5.7 loaded.

TCC  12.11.76   Windows 7 [Version 6.1.7601]
Copyright 2011  Rex Conn & JP Software Inc.  All Rights Reserved
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.)
 
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!!!).)
 
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
 
Perhaps running "handle.exe" from Sysinternals and searching through the
output might give a clue if something has it in use. Here's a
LINK<http://technet.microsoft.com/en-us/sysinternals/bb896655>
.

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

Somewhat possible, of course, although I have rebooted several times in the past week or so (I'm pretty sure that one (or more) of them were because of Microsoft's "Windows Updates", and it seems to me there were at least one or two more because some other issues(s) that I had). However, I will note here, if I have not done so before, that rebooting for me is an actually somewhat traumatic experience, both because this machine takes almost an hour to shutdown and reboot for whatever reason(s) and because it is, to a very high degree, my memory - at this moment I have 26 apps open (that doesn't include the typically three or four windows open in each of the four currently-open FireFox "sessions", nor does it include the (typically) three to four TCC sessions I have open in each of the (currently) six TCMD instances I have running; and I am currently in the "middle of" 39 "projects" of one kind or another (that number has been as high as 54 in recent memory!), 35 of them involving batch files in on way or another and 4 C++ programs, (I have a batch program to "do" this "counting" - TCC is wonderful!!!) and those numbers do not include the sometimes 4 or 5 or even more existing "versions" of a “project” file (I don't tend to delete something until I am absolutely sure without any doubt whatsoever that I won't have to go back to it). I also have so many "instances" of so many things open at one time because, they are, essentially, my "memory" of something I (have been and not yet finished) "working on". (I tend to “start” “projects” as soon as their “need” occurs to me just because the existence of the project “windows”, files, and directories are evidence that this is something that I want to accomplish; otherwise there is a very high likelihood that I will entirely forget about it until the next time I really need it.) And finally, as of this moment I have 479 .txt files on my RAM disk (in 168 directories/subdirectories) - many are things I need to remember (these files typically have fully-descriptive names such as (an actual real example!) "Rachael@Wachovia Home Mortgage Obama Plan Refinance.txt" - that is so I can easily find it if I can remember any of "Rachael", "Wachovia", "Mortgage", "Obama", or even "Refinance" - Rex's "wildcard" matching on things like directory searches (as well as the PDir command itself) are almost essential to my being able to live on my own) and this is why I have so many apps open. I will also note, as I’ve probably noted before, that due to my bad memory and poor eyesight and (to put it bluntly) general incompetence in general I am very slow to actually accomplish virtually anything!) And that is why, as you can probably figure out, I don’t like to reboot unless I absolutely have to.) And, as another note, I tend to guess that I am really a programmer by nature. In addition to the counts above, I have 41 C++ programs that I have written that were useful enough to make it to and remain in my “production” program directory (“D:\DOS”). There are also 95 batch (.btm) files in there that I thought were generally useful enough to actually keep. And if you are wondering why there are so many, the vast majority of them involve my finances in some way (keeping very close track of what I’ve already spent and making “predictions” about what I’m likely to spend in the future and what my financial “situation” will be if those things “come to pass” - and this is all because I live entirely on my Social Security Disability Income, which ain't very much) and/or my bad memory in some way (due to my bad memory and resulting general incompetence it would be quite accurate to say that I am quite paranoid about making a serious mistake that it will be very hard for me to “recover” from) so I have a lot of programs or batch files that “automate” various aspects of my life. And the final “category” of those falls into the general realm of automating something with multiple “steps” that I do on a “routine” basis, because the probability of me making a serious (and sometime unrecoverable) error is very high. One very good and easy-to-understand example of that is a .btm “program” that I wrote that “backs up” (by writing to a zip-like file on my RAM disk that is then written to a physical hard disk, and said batch file goes so far (again, because I am somewhat paranoid) as to verify that an exact copy of that compressed file makes it to the physical hard disk and that the data in the compressed file on the physical hard disk exactly matches the data that was put into it) everything that should be backed up on my RAM disk and has not already been backed up or has changed since it was last backed up (and that the compressed archive file actually contains all of that data).


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.
 
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])))
 
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: 327
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
>
>
 
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
 
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
 
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
>
 
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.)
 
Does this suggest that TCC should check the resulting path length when creating directory entries and warn about it?

TCC already checks to see if the path is > 260 characters, and if so it will prefix the filename with "\\?\".

The problem in this particular instance is that TCC cannot do that with recursive directory processing, as it would overwrite the values used in the parent directories.

I'll need to make an extensive change for build 33 to handle this condition. In the meantime, if you simply prefix your starting directory with "\\?\" the problem doesn't arise.
 

Similar threads

Back
Top