![]() ![]() ![]() When I go to the normal Windows Recycle Bin, any files that I have but into $RECYCLE.BIN" are not there.(Deleting a file in W: drive, however, does not send it to $RECYCLE.BIN - instead it is gone forever.) I can send files to this directory, and then send them out again.The W: drive has a hidden system directory called "$RECYCLE.BIN". (Note that I am only using encrypted containers I am not encrypting whole drives.) Suppose again that my encrypted VeraCrypt container has been mounted as W: drive. Pursuing the Recycle Bin option for a I gave up on the Recycle Bin because of the following. On the other hand, recording the "Original Location" would be more difficult, and would probably have to use Alternate Data Streams. 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 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. 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. Then on any other drive, "Delete" can move the file to the " directory. It looks as if the best solution is to teach the script what directories use the recycle bin, on each computer on our network. I looked a bit at WMI, but it seems exceedingly complicated, and googling produces other people asking the same question. (I later realised that I didn't actually need those two files.) 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. 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.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.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. 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.īut it doesn't resolve the problem of drives mounted by VeraCrypt (the standard TrueCrypt replacement). ![]() I could also abandon the Windows Recycle Bin on all drives for evermore, but this would be ungrateful to M$. 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. 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 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: on a mounted drive or USB drive. Within any drive X: it moves selected files and directories to the directory X: on the same drive (creating this directory first if it is not there already). To overcome this, I have written a very simple button-script. 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. ![]()
0 Comments
Leave a Reply. |