I use a flash drive to transfer software to other machine(s) on a relatively constant basis, and when I am done copying the stuff I want to transfer to the flash drive I use the Windows GUI (click on up-arrows on far right of the task bar and click on the "Safely Remove Hardware and Eject Media" icon) to "eject" the flash drive. Well I almost always (just like a moment ago) get a message box that states something to the effect of "Can't eject. Object in use.". So, I use the System Internals GUI "Process Explorer" program (The system-internals command-line "Handle" program effectively no longer works under Windows 7) to find out exactly which program(s) still have a "handle" on the "object", and it virtually always reports that "TCMD.exe" still has a "handle" on the flash drive. So I (I actually no longer bother to actually do this; you'll see why in just a moment) "shut down" all of my Take Command/TCC instances (I typically have an average of three or four of TCC instances in each of typically three to four Take Command sessions; I am a very heavy multitasker) which is kind of a pain in the rear because one the main reasons that I have so many sessions active is that I activate each TCC instance on a pretty much per-task basis and each TCC instance has its own "history" which means the commands I need to do for any one particular "task" are readily available using the up-arrow (and saving the individual "histories" to files before I exit each of the TCC instances is also kind of a pain in the rear because I not only have to save the histories (to individual files, one for each TCC instance, of course), I have to re-load them when I restart the individual TCC instances - also a pain in the rear which isn't really worthwhile in most cases. The multiple Take Command sessions exist primarily because I very often have one TCC window in which I want to do something based on the contents of another (one or more) TCC window(s) (this is largely a case of bad memory and my accommodations to same, and for me, at least, using Alt-Tab to switch from Take Command to Take Command session and therefore TCC instance to TCC instance is a lot faster and easier than any way I know of using the keyboard to switch from tab to tab in a single Take Command window.) The bottom line is that even after I do that there is typically at least one Take Command instance which still has a "handle" on the flash drive and I don't even have any Take Command sessions even open as far as I can tell. (Which is why I no longer bother to individually shut down the individual Take Command/TCC instances first; there's a very good probability that that won't even "solve" the problem anyway. And exactly why does a "Take Command" instance have a "handle" on anything??? And a completely invisible Take Command instance to boot??? What the heck is going on here???) So I "kill" (System Internals "PSKill" command) that one (or more) Take Command session(s) and I can then freely "eject" the flash drive and all is well. But exactly why do I have to go through all of this rigamarole in the first place???
WAD A small complaint re. Take Command and file (and particularly directory) handles...
- Thread starter mathewsdw
- Start date
- May
- 13,590
- 201
If TCC's (or TCMD's) current directory is on the removable device, then there's an open handle to that directory. Close them or make sure none have a current directory on the removable device (I don't think it's easy to tell what TCMD's CWD is).
As for invisible TCMDs ... I used to have a problem with TCMD destroying its window but not terminating ...haven't seen it in quite a while. If you're getting such zombie TCMDs that's a good topic for another discussion.
As for invisible TCMDs ... I used to have a problem with TCMD destroying its window but not terminating ...haven't seen it in quite a while. If you're getting such zombie TCMDs that's a good topic for another discussion.
The first case is not the case. And to some degree the "zombie" TCMD's were the main point of bringing up the issue in the first place but this is the only situation in which I really care. (The rather small amount of memory they may take up is largely irrelevant when you have over 3GB of RAM, and I have no indications at all that they use much (if any) CPU time.)
rconn
Administrator
- May
- 13,534
- 239
Staff member
The only time Take Command will have a handle to a directory is if you have that directory selected in your List View.
The only time TCC will have a handle to a directory is if it is your current directory.
Both of those are normal Windows behavior; you'll get the same result using Explorer or CMD.
The only time TCC will have a handle to a directory is if it is your current directory.
Both of those are normal Windows behavior; you'll get the same result using Explorer or CMD.
Rex,
While I certainly wouldn't argue with the fact that that is what you think and that even may have been once true ("list" and/or "current directory") in my situation; it totally ignores the facts that, as I said, closing all of my "visible" running Take Command sessions does not clear up the problem; and "killing" the PID(s) of the (TCMD!) process(es) that Process Explorer claims have handle(s) on the flash drive does clear up the problem with no visible instances of Take Command "going away" (after I stopped "automatically" closing Take Command sessions), and those are the facts (after "experiencing" this problem for several months at a minimum I'm quite sure of that!!!). (And yes, I know that these are "normal Windows behaviors for running Windows applications; the issue is that these do not "appear"(!) to be (any longer!) "running" Windows applications.)
And if you really don't believe me (which wouldn't really surprise me at all) the best I can do is exhaustively "document" the situation (by screen shots and whatever) the next time it happens; which it almost certainly will.
- Dan
P. S. In fact, in the past I have shut down all visible instances of all of the programs I was running at that moment (Microsoft Word, Excel, FireFox, etc. etc. etc.; and even the Windows "Magnify" app) such that the "Applications" tab of the standard Windows "Task Manager" window was entirely empty (no user program(s) whatsoever other than the Task Manager itself running) and the problem still existed unless and until I somehow "killed" the (TCMD!!!) PIDS responsible.)
While I certainly wouldn't argue with the fact that that is what you think and that even may have been once true ("list" and/or "current directory") in my situation; it totally ignores the facts that, as I said, closing all of my "visible" running Take Command sessions does not clear up the problem; and "killing" the PID(s) of the (TCMD!) process(es) that Process Explorer claims have handle(s) on the flash drive does clear up the problem with no visible instances of Take Command "going away" (after I stopped "automatically" closing Take Command sessions), and those are the facts (after "experiencing" this problem for several months at a minimum I'm quite sure of that!!!). (And yes, I know that these are "normal Windows behaviors for running Windows applications; the issue is that these do not "appear"(!) to be (any longer!) "running" Windows applications.)
And if you really don't believe me (which wouldn't really surprise me at all) the best I can do is exhaustively "document" the situation (by screen shots and whatever) the next time it happens; which it almost certainly will.
- Dan
P. S. In fact, in the past I have shut down all visible instances of all of the programs I was running at that moment (Microsoft Word, Excel, FireFox, etc. etc. etc.; and even the Windows "Magnify" app) such that the "Applications" tab of the standard Windows "Task Manager" window was entirely empty (no user program(s) whatsoever other than the Task Manager itself running) and the problem still existed unless and until I somehow "killed" the (TCMD!!!) PIDS responsible.)
- May
- 382
- 2
Do any of your command prompts start ShrAlias? In that case make sure to unload it before unplugging, ShrAlias /U.
- May
- 382
- 2
Not that I am aware of (but that could be yet another instance of bad-memory). But the only "plugins" (guessing that "ShrAlias" is a plugin) that I have loaded are "ISO8601 v1.1.1", "SafeChars v1.6.1", and "Sift v0.55.0". (And "ShrAlias /U" "reports" that "SHRALIAS not loaded"; and trying to "run" ShrAlias reports "No shared memory found".)
rconn
Administrator
- May
- 13,534
- 239
Staff member
I am 100% certain that TCMD never, ever, ever, holds a handle to a subdirectory unless you've made it the current directory. I mount & eject USB drives dozens of times every day on multiple systems (all with TCMD running), and have never had Windows refuse to eject it (unless I really was in that directory).
Your issue seems only marginally related to the directory handle. If you really have "zombie" TCMD processes running, you need to determine how they arrived at that state. (Vince's similar problems were only reproducible on his system, and only using the v11 beta, so I doubt that's related.)
Your issue seems only marginally related to the directory handle. If you really have "zombie" TCMD processes running, you need to determine how they arrived at that state. (Vince's similar problems were only reproducible on his system, and only using the v11 beta, so I doubt that's related.)
Stefano, that is what I am running, and I quote:
And, as I've said, "handles" created in non-administrative mode are not necessarily "visible" to programs (specifically the "Handle" program!) running in administrative mode. I can't begin to tell you how many times I've gotten the message when trying to delete or rename a file that it "is in-use by another process" and an immediately following "Handle" command invocation results in "No matching handles found." and immediately following that by another attempt to delete or rename the file results in the same "in-use" error message.
- Dan
Code:
Handle v3.46
Copyright (C) 1997-2011 Mark Russinovich
Sysinternals - www.sysinternals.com
Initialization error:
Make sure that you are an administrator.And, as I've said, "handles" created in non-administrative mode are not necessarily "visible" to programs (specifically the "Handle" program!) running in administrative mode. I can't begin to tell you how many times I've gotten the message when trying to delete or rename a file that it "is in-use by another process" and an immediately following "Handle" command invocation results in "No matching handles found." and immediately following that by another attempt to delete or rename the file results in the same "in-use" error message.
- Dan
And Rex, I'm pretty much 100% sure that I did, in fact, once have my CWD on the flash drive (since I pretty much do 100% of everything from the command prompt - because of my vision issues the Windows GUI is virtually unusable for me) makes that highly likely. The issue is 100% that Take Command sessions that I am closing are not entirely closing! (And just so there is absolutely no doubt here: TCC 12.11.76 Windows 7 [Version 6.1.7601]).
- Dan
P. S. And in terms of how they arrived at that state I have clue what it could be (because I run nothing but Take Command/TCC and "standard" Windows programs - although, now that I think about it I start pretty much 100% of my (Windows GUI!) "applications" from the command prompt using "aliases" most, but not all (however, the only ones I can identify are invoking Notepad), of which explicitly use the "start" command, and there are a very few things that I "start" directly from the command line without using a "Start" command (FireFox is the only one that comes to mind; its directory is in my path and I didn't see any need to define an alias for it) and maybe it's one or more of them that is causing the problem. Although, as I said above, I've closed down literally all of my running apps and the problem has not gone away.
- Dan
P. S. And in terms of how they arrived at that state I have clue what it could be (because I run nothing but Take Command/TCC and "standard" Windows programs - although, now that I think about it I start pretty much 100% of my (Windows GUI!) "applications" from the command prompt using "aliases" most, but not all (however, the only ones I can identify are invoking Notepad), of which explicitly use the "start" command, and there are a very few things that I "start" directly from the command line without using a "Start" command (FireFox is the only one that comes to mind; its directory is in my path and I didn't see any need to define an alias for it) and maybe it's one or more of them that is causing the problem. Although, as I said above, I've closed down literally all of my running apps and the problem has not gone away.
rconn
Administrator
- May
- 13,534
- 239
Staff member
Unfortunately, I cannot investigate and fix anecdotal bugs. If you have a reproducible failcase, post it here and I will try to reproduce it on my end. START cannot have anything to do with it (unless you're START'ing into another TCMD tab) because it would be running in a separate session.
Similar problems in the past have all been traceable to either a problem in the user's TCEXIT, or a third-party dll that had injected itself into TCMD.EXE and was refusing to shut down.
Similar problems in the past have all been traceable to either a problem in the user's TCEXIT, or a third-party dll that had injected itself into TCMD.EXE and was refusing to shut down.
Well that's kind of what I thought which is why I wasn't consistently using the "Start" command. I really don't know at this point in time whether it's worth wasting any more of my (or your) time on since it does have a "solution". (ProcessExplorer and PSKill aren't all that "painful", although having to use them (particularly the GUI for ProcessExplorer) is irritating). Thank you, Rex!
- May
- 13,590
- 201
Rex, TCMD must have a current directory. What determines it? What determines TCMD's startup directory?
Dan, a reproducible way of creating those TCMD zombies would be a good start. If I recall correctly, my getting them was (inexplicably) related to the UpdateTitles directive, to TITLEPROMPT being set or not, and to the existence or non-existence of a TCEXIT file. I could reproduce them with ease but no one else could.
rconn
Administrator
- May
- 13,534
- 239
Staff member
The List View directory is TCMD's current directory. The startup directory is determined by Windows Explorer (or whatever program you use to start TCMD).
Vince, I have a TCStart.btm (which just exits if it is being invoked by a shell where %_Pipe != 0 or %_Transient != 0; runs through all of my drives CDing them to their root directories; sets the TitlePrompt to "PID %_PID"; and assigns drive letter Z: to drive letter J: if Z: is not defined - this is how the Z: to J: subst was being done in both administrative and non-administrative mode but I didn't remember the specifics yesterday ) but no TCExit.btm; and I don't even know what the "UpdateTitles directive" is and the "help" file returns "No topics found" if I search for it.
- Dan
- Dan
- May
- 13,590
- 201
What directory does TCSTART leave TCC in (could that be an issue)? As I recall I needed a TCEXIT file to get the zombie TCMD processes. "UpdateTitles" is in the OPTION dialog "Startup" tab (press "Help" while there); it determines whether your console window caption will reflect the current task or remain constant. In any event, being able to get a zombie TCMD on demand will help everyone get to the bottom of that problem and solving that problem may solve your removable drive problem.
Vince, thank you for reminding me what/where "UpdateTitles" is; I dimly remembered it once you mentioned it, and I even have it checked!!!! (Although I get the impression from the help file that that may be default. And I didn't find it in the help file previously because I wasn't putting the space between the "Update" and the "Titles".)
And TCStart "leaves" me in the root directory of the Z: drive (RAM disk, of course), which is where I want to be very close to 100% of the time.)
- Dan
And TCStart "leaves" me in the root directory of the Z: drive (RAM disk, of course), which is where I want to be very close to 100% of the time.)
- Dan
- May
- 382
- 2
Dan, if you SUBST drives in non-admin and admin modes, you're multiplying the ways a locked filepath may be named in the system. So, i.e., J:\file may not be locked in Dan's user account, but the equivalent Z:\file could indeed be locked in Administrator's user account. You need to take this into account when sercing for locked handles with handle.exe and Process Explorer.
Another point. Unlike Windows XP, Windows 7 attaches each console program to an extra process, conhost, which itself could lock a handle. Occasionally I've observed conhost hanging around after its TCC 13 peer had completely exited. That conhost zombie was preventing me from ejecting the portable drive.
- Jun
- 793
- 7
You can tell Windows to not cache writes to the drive so you don't have to do Safely Remove. In fact, I believe this is the default for Windows 7. Right-click the drive and select Properties > Hardware > the drive > Properties > Policies > Optimize for quick removal.
First just as a possible apology: I thought I had submitted this earlier today but looking at this thread now I see no indications of its very existence for reasons I truly don't understand! So if this posting is, in fact, a duplicate (which I really tend to doubt at this moment but I can't be sure), I apologize. So on to the point:
Stefano, all of what you say above is (obviously!) true, but it's always either somewhat off-topic or just plain irrelevant.
So, point by point:
As to the program that I wrote that does the "subst" processing I mentioned above, as I've often mentioned I'm quite paranoid and the sum total of my disabilities makes the probability of me making mistakes quite (in fact, unacceptably) high, so I practice what you might call "safe computing" wherever that is possible; and I am now totally unaware of any situations where that is not possible. So, since I often "move" data from one drive to another (mainly, but not entirely, because my primary "working environment" is a RAM disk, but also when I am transferring (not just copying; remember my internal hard drive partitions are both above 98% full, so I really have no option but to delete stuff on them that I do not believe that I will need relatively "immediately", if ever) data from an internal to the external hard drive), I never, ever, under any circumstances whatsoever, just move that data (I've actually got the "native" "move" command aliased to "Echo Can't do that, you must do a copy!" (primarily in case I get a batch file from someone/somewhere that does do "moves"); and the Windows GUI (which I don't really use anyway) copies unless you explicitly tell it to "move" (click the right-arrow and you get a "pop-up" menu containing same), which I would absolutely never, ever, do even assuming that I ever used the GUI in the first place, which I don't.) I copy that data from the source to the destination and then invoke this program on same. Said program then "runs through" the directory trees on both the source and the destination and if the program finds that the files on the destination exactly match the "source" files ("exact" can mean any one or more (even all) of: same name (always), same size, same last-modification date/time, attributes (excluding the read-only attribute because I generally make all of the files in the destination directories read-only after copying them there) and, byte-by-byte, contents; and said program can then either "prompt" me as to whether to delete the now-proven-to-be-identical source file(s) or just go ahead and do it automatically (sometimes I want the one, sometimes I want the other; the first particularly if I am copying files related to a program that I am working on but am not yet necessarily done with and the "version" I am copying is a "solid" intermediate step). Said program even has a "/N[o]" (delete) option and a "/R[everse]" option that I use just to ensure that two directory trees are completely "synchronized". And I absolutely do not, of course, want that program to delete a "source" file when that is literally the same file ("hardlinks" are not considered to be the "same") as the "destination" file (on the same, "real", drive letter at the same INODE as the "source" file) because doing so would, of course, effectively delete both (really 1!) file(s). (In fact, if the program determines that two files are really the same "physical" file (hardlinks excluded) which it would do right at the start it does no further processing of any kind on that file and the directory containing that file and the subdirectories of the directory containing that file if two files are really the same physical file because of one or more of SUBST'd drives, junctions, and symbolic links there's no point in further processing the directory containing that file or its subdirectories - once determined to be true for one file in a directory it will remain true for all of the other files in both that directory and its subdirectories.)
And just as a note regarding "hard links", which I use quite frequently, I have another program that runs through (possibly some selected part) of the file system that, if it determines that two files have the same name and contents but are not the same file (INODE) on the same physical "partition" it "renames" one of the files to contain the word "NowHardLinked" (out of paranoia so I can go back and verify things and manually delete them after the fact If I'm satisfied that their contents are identical) and then makes a new file using the original name of the now-to-be hard-linked file that is, in fact, actually hard-linked to the other file. I decided that I had a (slight) preference for making this a "standalone" process over including it in the program above or some kind of "copy" program.
And if you are curious as to why I so often use hard and symbolic links (and junctions prior to Windows 7) it is due to a combination of both my impaired memory and almost-full disk-drive partitions. I can therefore find files wherever I feel that they probably should be at any given moment (bad memory) and they will be there and yet not take up any "significant" real disk "real estate" (almost-full partitions) with almost no negative "consequences" whatsoever.
Stefano, all of what you say above is (obviously!) true, but it's always either somewhat off-topic or just plain irrelevant.
So, point by point:
Almost certainly true for at least some programs/"pieces" of the OS which aren't "smart" enough to detect and "track down" SUBST'd drives. (Note: I myself wrote C++ code than can and does do this; code which I run on an almost-literally daily basis for which I considered this then and still consider this now to be an essential requirement for said code. Said code also entirely handles junctions and symbolic links. And if you are curious as to what the program using that code does see the bottom of this posting, I'm going to put it there because it's rather long and then people can just quickly decide to ignore it if they do not want to read it, which they very well may not! :))
Stephano, I really don't understand you here, but that certainly may be because you misunderstand what I am doing. I am not doing some things in "Dan's" account and others in a true, but separate, administrative account; I am doing some things (and not at all very often) in "elevated" command prompts, and pretty much everything else I possibly can (unless I'm going to get the "requires administrative privileges" message box literally dozens of times) from a "normal", non-elevated command prompt. And this is simply because that due to the sum total of my disabilities I find the probability of me making a significant mistake that I will truly very much regret having made too high to do otherwise.
Well-documented and well-known, even by me. But it is not "conhost" processes that are identified as having handles on the flash drives, it is 'tcmd" processes.
As to the program that I wrote that does the "subst" processing I mentioned above, as I've often mentioned I'm quite paranoid and the sum total of my disabilities makes the probability of me making mistakes quite (in fact, unacceptably) high, so I practice what you might call "safe computing" wherever that is possible; and I am now totally unaware of any situations where that is not possible. So, since I often "move" data from one drive to another (mainly, but not entirely, because my primary "working environment" is a RAM disk, but also when I am transferring (not just copying; remember my internal hard drive partitions are both above 98% full, so I really have no option but to delete stuff on them that I do not believe that I will need relatively "immediately", if ever) data from an internal to the external hard drive), I never, ever, under any circumstances whatsoever, just move that data (I've actually got the "native" "move" command aliased to "Echo Can't do that, you must do a copy!" (primarily in case I get a batch file from someone/somewhere that does do "moves"); and the Windows GUI (which I don't really use anyway) copies unless you explicitly tell it to "move" (click the right-arrow and you get a "pop-up" menu containing same), which I would absolutely never, ever, do even assuming that I ever used the GUI in the first place, which I don't.) I copy that data from the source to the destination and then invoke this program on same. Said program then "runs through" the directory trees on both the source and the destination and if the program finds that the files on the destination exactly match the "source" files ("exact" can mean any one or more (even all) of: same name (always), same size, same last-modification date/time, attributes (excluding the read-only attribute because I generally make all of the files in the destination directories read-only after copying them there) and, byte-by-byte, contents; and said program can then either "prompt" me as to whether to delete the now-proven-to-be-identical source file(s) or just go ahead and do it automatically (sometimes I want the one, sometimes I want the other; the first particularly if I am copying files related to a program that I am working on but am not yet necessarily done with and the "version" I am copying is a "solid" intermediate step). Said program even has a "/N[o]" (delete) option and a "/R[everse]" option that I use just to ensure that two directory trees are completely "synchronized". And I absolutely do not, of course, want that program to delete a "source" file when that is literally the same file ("hardlinks" are not considered to be the "same") as the "destination" file (on the same, "real", drive letter at the same INODE as the "source" file) because doing so would, of course, effectively delete both (really 1!) file(s). (In fact, if the program determines that two files are really the same "physical" file (hardlinks excluded) which it would do right at the start it does no further processing of any kind on that file and the directory containing that file and the subdirectories of the directory containing that file if two files are really the same physical file because of one or more of SUBST'd drives, junctions, and symbolic links there's no point in further processing the directory containing that file or its subdirectories - once determined to be true for one file in a directory it will remain true for all of the other files in both that directory and its subdirectories.)
And just as a note regarding "hard links", which I use quite frequently, I have another program that runs through (possibly some selected part) of the file system that, if it determines that two files have the same name and contents but are not the same file (INODE) on the same physical "partition" it "renames" one of the files to contain the word "NowHardLinked" (out of paranoia so I can go back and verify things and manually delete them after the fact If I'm satisfied that their contents are identical) and then makes a new file using the original name of the now-to-be hard-linked file that is, in fact, actually hard-linked to the other file. I decided that I had a (slight) preference for making this a "standalone" process over including it in the program above or some kind of "copy" program.
And if you are curious as to why I so often use hard and symbolic links (and junctions prior to Windows 7) it is due to a combination of both my impaired memory and almost-full disk-drive partitions. I can therefore find files wherever I feel that they probably should be at any given moment (bad memory) and they will be there and yet not take up any "significant" real disk "real estate" (almost-full partitions) with almost no negative "consequences" whatsoever.