I've been using DOpus for about 1.5 months now and I just did something incredibly frustrating for the third time with DOpus - something that I've never done a single time in maybe 10+ years of using Windows Explorer before that. I accidentally deleted an entire directory because I thought I had a single file selected, when in fact the directory itself was selected. After smashing a few things and using an undelete tool to get some of the stuff back (albiet with mangled directory structures) I feel compelled to point this out as I absolutely would regard this as an anomaly – not a bug per say (although you could make the argument), but at the very least unexpected functionality that can bite you in the, well you know what I mean.
Here’s the scenario. Let’s say I have folder C:\foo, and inside C:\foo I have several dozen subfolders, as well as dozens or hundreds of files I’ve downloaded – many in multi-part RAR archives. I’m unpacking them into directories and deleting the source RAR archives after I’ve unpacked their contents. Normally after I delete a file (or files), the next file in the directory is selected. However occasionally (3 times so far), the parent directory C:\foo is also selected – and here’s the bad part. The visual appearance of the selected file within a directory is identical whether the parent directory is selected or not. So, when I delete (or as I often do, shift-delete – sure, it’s harder to recover, but as I said in 10+ years this has never been an issue before), the entire parent directory is deleted, leading to much cursing and occasional breakage of objects.
The killer part here is that if there are sufficient subfolders in C:\foo, I don’t actually see C:\foo in the left hand pane (in this case I’m just using Explorer view) as it has scrolled off the top. So I can’t see that it’s selected and, as the “selected” appearance of the file within C:\foo is no different whether the parent folder has focus or not, there is no reason for me to think that I’m about to delete my entire directory. In fact, the first two times it happened I had absolutely no idea what had just happened – it’s only after a bunch of investigation that I realized this is the case.
So here’s my suggestion – I have no idea why occasionally the parent get’s focus when normally it doesn’t, and ideally this wouldn’t happen unexpectedly. However, if the parent of the folder get’s focus (e.g. is the thing that will be deleted if you hit delete), then any file or files within the folder should be clearly indicate that they’re no longer focused – perhaps simply by changing the black background to grey, as is done with the parent.
I’ve taken some screenshots to illustrate this problem. In the first set you can see the parent folder in the left hand pane, and while it’s appearance clearly changes when it gets focus, the file in the right hand pane barely changes (an imperceptibly small dotted outline disappears – can you see the difference?).
The second set illustrates the real killer situation – because of the number of subfolders, you can’t even see the parent folder. How many of you can spot the difference between the two shots (look close, it’s there).
Anyway, sorry about such a long post, but I wanted to make sure it was very clear that a) this is an actual phenomenon and b) simply telling me not to shift-delete so I can use undelete misses the point, as that’s an end user work around for pretty counter-intuitive behaviour by the program, rather than just eliminating the counter-intuitive behaviour. That, plus I just wasted an hour and a half trying to recover the files I deleted (and some of them I didn’t even get back).