How to test whether a drive is a mounted drive?

When I use a USB flash drive as say X: drive, or mount a VeraCrypt encrypted container using a drive-letter such as X: drive, deleted files do not go into the Windows Recycle Bin, but simply disappear.

To overcome this, I have written a very simple button-script. Within any drive X: it moves selected files and directories to the directory X:@ForDeletion on the same drive (creating this directory first if it is not there already). I now want to complete the procedure by tweaking the standard "Delete" command so that within DOpus, the "Delete" button deletes to the recycle bin on ordinary directories, but to X:@ForDeletion on a mounted drive or USB drive.

PROBLEM: How do I test, within the DOpus button-script, if the source drive is a mounted drive or a removable drive (or a DVD drive, or something else again)?

I could, of course, give the script a list of the ordinary drives on each computer on my home network, but this seems not to be an elegant solution. I could also abandon the Windows Recycle Bin on all drives for evermore, but this would be ungrateful to M$.

This could work for you to determine the drive type (with "mounted" drive, I guess you mean "network"?).

var fso = new ActiveXObject("Scripting.FileSystemObject"); var driveType = fso.GetDrive("C").DriveType; // 0 = unknown // 1 = removable // 2 = fixed // 3 = network // 4 = CD-ROM // 5 = RAM disk
There is also WMI to query drive and volume information.
The column Link2Volume I uploaded once, contains all necessary bits to detect what kind a given location is.

Thanks, tbone, "driveType" resolves the problem of USB drives, network drives, and DVD drives very easily, and I should have remembered it because I used it only a few weeks ago.

But it doesn't resolve the problem of drives mounted by VeraCrypt (the standard TrueCrypt replacement). When I mount an encrypted VeraCrypt container as a drive, say as W: drive, then "driveType" reports it as Type 2, that is, as a fixed drive, so that within the script, W: drive is indistinguishable from C: and D: drives.

• This is odd, because Windows does not send files deleted from W: drive to the Recycle Bin, so Windows must know that it is not an ordinary drive.
• Also, W: drive does not show up in "Disk Management" in the Control Panel, so again, Windows knows that W: drive is different from C: drive and D: drive.

It was deletions yesterday of a couple of financial records from this particular W: drive that made me realise how important an Ersatz Recycle Bin is. (I later realised that I didn't actually need those two files.)

I looked a bit at WMI, but it seems exceedingly complicated, and googling produces other people asking the same question. It looks as if the best solution is to teach the script what directories use the recycle bin, on each computer on our network. Then on any other drive, "Delete" can move the file to the "@ForDeletion" directory. Alternatively, because I only mount Veracrypt drives using DOpus buttons, I could easily create a non-persistent DOpus global variable that records the drive letters of all mounted drives.

On a different point, the moved file or directory needs a date–time stamp on the end for when it is deleted, otherwise there are duplication problems with directories — this is because the standard DOpus command "Copy Move WhenExists=Rename" works for files, but for some reason that I don't understand it doesn't work for directories.

No worries, because the "Date Deleted" is an essential feature of the normal Recycle Bin, and adding it to the filename is the best method of recording it. On the other hand, recording the "Original Location" would be more difficult, and would probably have to use Alternate Data Streams.

The recycle bin works with TrueCrypt / VeraCrypt drives, or can do at least.

Why not make the script look for the recycle bin folder on the drive? That will tell you if the drive is likely to support the recycle bin.

Yes, the recycle bin trick sounds good, I was thinking about a custom file or folder at first, but the bin should do it just as well, as long as it is enabled (I guess the recycle.bin folder then dissapears on those drives?). Another possibility, which get's you around testing for driveletters, is testing against the volume ID, as that is not going to change for a volume (letters can). You'd need to register/enter the IDs of all the mounted crypt-volumes in your script though, which can also be unhandy of course, if you have many crypted volumes to handle.

To find the volume ID of your mounted crypt-volume, you can use "mountvol.exe".

Pursuing the Recycle Bin option for a moment:

@leo, I gave up on the Recycle Bin because of the following. Suppose again that my encrypted VeraCrypt container has been mounted as W: drive. (Note that I am only using encrypted containers; I am not encrypting whole drives.)

The W: drive has a hidden system directory called "$RECYCLE.BIN".

• I can send files to this directory, and then send them out again. (Deleting a file in W: drive, however, does not send it to $RECYCLE.BIN — instead it is gone forever.)
• When I go to the normal Windows Recycle Bin, any files that I have but into $RECYCLE.BIN" are not there.
• On the normal Windows Recycle Bin, W: drive does not show up on "RightClick - - > Properties".

Inside $RECYCLE.BIN" is another hidden system object called "Recycle Bin", described in its properties as a "file folder". It seems to be some sort of link.

• When I left-click on it, I get what looks like the normal Windows Recycle Bin, and as before, any files that I have sent to $RECYCLE.BIN are not there. The breadcrumb name at the top of the lister is "W > $RECYCLE.BIN > Recycle Bin", and when I click to the right, the name changes to "W:$RECYCLE.BIN\S-1-5-21-2416837597-2678249377-705536697-1001".
• If instead I right-click on "Recycle Bin" and go to Properties, I get "Recycle Bin Properties", but with three headers instead of the usual one. Still W: drive is not mentioned, so I have no idea how to configure this recycle bin.

If I drag a file in "$RECYCLE.BIN" into "Recycle Bin" it is gone forever.

That's why I gave up and tried to create my own system (which, by the way, also works for USB flash drives).

UPDATE:
I have just been searching the VeraCrypt website. This behaviour may be a the result of a temporary bug in VeraCrypt. I'll wait a little until the situation clears before installing any "nightly builds", but it may be that at least the VeraCrypt situation will be resolved soon: https://veracrypt.codeplex.com/discussions/645558 . No good for USBs, however.

SUCCESS 1: I have just installed the new version 1.16 of VeraCrypt, and the Windows Recycle Bin now works as it should, so what I reported was indeed a bug, which has now been corrected. Thanks, @leo, for your tip, which sent me to the VeraCrypt forums. Installing VeraCrypt betas may not have been such a good idea, given the "mission critical" nature of the programme.

SUCCESS 2: I now have two button-scripts, the first for "deletion" to a special directory "X:@ForDeletion" on the same drive, say X:, and the second for "restoration" of the "deleted" file. I managed to store the "deletion" date, the modified date and the original path in the "User Description" column so that the restored file can be given its original location, name and date modified.

These two button-scripts are, of course, still useful when working with files on USB flash drives or on mapped network drives, so I presume that it would be worth posting these when I have finished cleaning up the code?

Yes, please do so! o)

I can remember several times where I deleted stuff over the network and noticed a second later, what a a bad idea that was with no way to undo the action. Seems we need a new EmptyRecycleBin functionality with that as well.. o) You maybe wanna look at "LogCommand" a script command I did, which I put in front of every DO command that moves/copies/deletes stuff. It logs into csv-files what files where affected by what command and what the specific source-, destination-locations have been.

I've now posted the two buttons, “Deletion“ and “Restoration“, at
[url]Ersatz Recycle Bin for USB drives and mapped network drives]

@tbone, I didn't go to a CSV-file solution because it seemed much easier to tuck the information needed into the metadata field “User Description“. It works, but it may not be the most elegant solution. I've made a few other comments about the situation in the post, plus some possible extensions to further situations.