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:
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.
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
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! :))
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 searching for locked handles with handle.exe and Process Explorer
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.
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.
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
, 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
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