phkhgh said:
Thanks. You added another about testing while I was writing this. BTW, why doesn't this forum have posts numbered in a corner, so they can be referred to ("in post 3, he said")?
phpBB doesn't have this feature, apparently. I guess people will have to count (gah!)
phkhgh said:
At beginning of your next to last comment, you seem to be thinking out loud. I often do. Users (I) could monitor each of the 2 eraser processes, but that's not something avg users would do or be expected to.
Yes, that design is deliberate; hence I wasn't too surprised when you thought I was kidding when I said
which Eraser process crashed.
phkhgh said:
It is also possible that the second instance did its job and exited normally
This is important to a developer or someone w/ access to & knowledge of the code, but to avg users, if it crashes, it crashes.
Indeed! Hence I pointed it out. As you mentioned, it isn't an intuitive behaviour for programs, especially when it's hidden. The alternative (that is, to let users be aware of it) would only cause more confusion.
phkhgh said:
I find much more often now w/ v6 stable & v 6 nightlies than in most of v5x's, when Eraser encounters something it doesn't know how to handle or doesn't like, it locks up & must be manually closed. That was pretty rare for me in v5.x.
Try disabling the force unlock files to be erased feature and see if that allows the files to be erased.
I will, but it seems like I've had to flip flop between enabling / disabling "force locked files to be erased" for a long time. Is the code to unlock files written by Eraser developers? I can't say I've NEVER used a prgm that claimed to be able to unlock files & not once failed (especially non system), but it's pretty rare & didn't cause crashes. It's a neat feature if works, but in Eraser's case, seems to be a sticking point that regularly causes problems. If it doesn't work fairly consistently (lots of posts about it), maybe take it out until it does work.
I wrote the code with some inspiration from a Sysinternals forum post. Their main idea was to call into the Windows NT native API, access handle information, and close them as necessary. It worked on my system and its particular configuration almost all the time, and has never once crashed (until this morning -- though I do not know what crashed since no messages were given to me, the Eraser process just disappeared.)
In short, I just short-circuited Windows. Is there any risk? Yes, most programs where the handle was expected to be open will crash or error out, but that's the point isn't it? Eraser
may crash doing so, but internally that didn't happen to me before. The most delicate part of the unlock code is mapping numbers to filenames, but even then it has got fallback mechanisms which should prevent a crash.
phkhgh said:
Looking back now over many months of testing nightlies, I can see how many, many crashes could have been caused by probs w/ file unlocking. Either when 1 or 1 of 10 files selected was locked (& I didn't realize it), Eraser would crash. Maybe make it disabled by default & a note in UI that it's still a beta feature.
I haven't tested dozens of wiping prgms & definitely not being disrespectful, but haven't encountered many probs w/ prgms like CCleaner, File Shredder. They don't have the other features Eraser does, of course. But it appears if they encounter locked files they can't erase, either schedule them to be erased at restart or just report unable to erase them - but not cause a prgm crash. Maybe.... part of the reason is they don't try to unlock files. Really don't know - guess I could do a little testing.
Indeed, features bring bugs. A one-liner program cannot crash. But one-liner programs do not do anything useful. I guess I'm being rather ambitious here... which I do hope is for the good of the community.
I would need more information to be able to accurately diagnose crashes - the Unlocker code is written in C++ (not the managed C# the rest of the program is written in: C++ is a more machine-like language and was not designed to be a first-class .NET language) and for that to happen I would need a memory minidump (thank goodness those are only about 300kb) but to collect one would require lots of intervention on the part of the user and probably guided help over a more real-time communication tool (IM, or voice conversation)
BlackBox in 6.2 should be able to collect such crashes, but I do not think the BlackBox crash trapping code will trip when the crash is below the .NET framework (like I said, Unlocker is written at a level lower than .NET)
phkhgh said:
You mentioned being in a catch 22 (do users < 40 know where that phrase came from?). Why is that? I may have given you the info so you, Joel - lord of the coders - single handedly may have found the source of a problem that's irritated users for a long time. What is the catch 22 part?
Unless I can get Eraser to crash consistently, I have to dismiss this as "it works for me." Removing it would cause complaints from users where the feature
does work, leaving it will cause complaints from users where the feature
doesn't work.
I'm quite certain that the feature does work for the silent majority -- I mean, what's there to complain if the feature
works, and it's not human instinct to drop by the forum and say that the feature works. Hence the number of reports of a broken Unlocker feature woul seem to be excessive relative to the number of people using it.
