Can't erase more than 16 files (eraser 5.8.7)

R

Rein

New Member
Firstly OS is Windows 7 x64 and from testing affects all previous versions of eraser 5. The issue is that using the context menu when more than 16 files are selected does nothing.

Debugging the issue took me to line 289 of ErasextMenu.cpp
Code: 
if (!HIWORD(lpici->lpVerb) && CMD_ERASE == LOWORD((DWORD)lpici->lpVerb) || CMD_MOVE == LOWORD((DWORD)lpici->lpVerb) )

When selecting 16 or less files the debugger tells me that lpverb is 0x0000000000000000 <Bad Ptr> this I assume is the correct and desirable option corresponding to the CMD_ERASE

When more than 16 lpverb is 0x00000000026ddac0 "Erase file(s)" not so good I suspect?

Interestingly the move command has no issues what so ever correctly showing 0x0000000000000001 <Bad Ptr> no matter how many files are selected

As to the cause of this I have no idea, it was working no issues but I have been messing with various odds 'n' ends windows option wise so I assume I've turned something on or off that induces this behaviour. Anyway any advice or random suggestions are welcomed.
 
It's not really your fault - it's the way Explorer handles ANSI (non-Unicode) shell extensions. Since we compile Eraser with ANSI instead of Unicode (since the code dates back to Win98) Explorer does this behaviour for selections with greater than 16 files... and we can't switch to Unicode either because all the libraries aren't written to support Unicode. So I guess the only way out here is to try v6 (which does use Unicode)

Joel
 
Is that the reason, I had a look at the example in the help files on it where it uses both the low bit, as used in eraser, numerical passing and the hi bit text passing but it gave no indication of the whys and whatfors of it.

I'd figured it must have been something I set as it had been working with no issues, in fact less issues than on XP x64 as that issue I had with files being locked if I turned on Alternate Data Streams was gone. It all went bad after I had finished messing with random options. Ah the mess gpedit gets me in, just spent a few hours figuring out that the reason most of the links in document explorer didn't work was cause I'd turned off all the activex add-ons for IE.

Anyway thanks for the info.
 
Yep we're following the documentation in MSDN in terms of specification and adherence to the spec, but Explorer just gives us weird info, so it's not something within our power to change... sadly.

Joel
 
Firstly I just tested Eraser 6 and it also shows the same behaviour, more than 16 files and it won't work throws an error about how Eraser could not be started. Looking at the code its most likely the exact same issue, I can't debug properly as I can't seem to get the Eraser 6 code to compile for whatever reason.

Playing with the Eraser5 code, in a totally incompetent manner, all thats required to get this working normally again is handling the lpVerb this seems to involve changes to several locations in ErasextMenu.cpp

As mentioned above the lpVerb contained the string from the string resource table, if I were to try to erase with a directory selected it would have the IDS_COMMAND_STRING_DIRECTORIES string. This is caused by the CErasextMenu::getstr_handle_erase(UINT nType, CString& cmdstr) function (line 522) by handling the nType here and serving the GCS_VERBW GCS_VERBA types with a suitable verb it means that you can do a check for that verb when the hiword returns true in the InvokeCommand function from above(line 289). This results in all the normal context menu functionality and so far nothing untoward has occurred.

I still have no idea why this is happening, what is so special about selecting more than 16 items that makes windows feel like using a string rather than the normal system? Why has it started doing this? Its not like its the kind of thing you'd expect to be user changable.

Anyway hopefully its clear that I have no idea what I'm talking about, that the consequences of what I've done are totally lost on me etc

Oh and this probably doesn't matter much but Eraser5 doesn't seem to have any issues with having ASLR turned on, based on my woefully limited testing
 
Haha, if you've debugged this far you are a very competent (even a very good) debugger! You don't need to deprecate yourself like that, haha.

I've done some analysis - Eraser 6 doesn't have the problem. I just deleted 21 files without any issue. What is the error you are getting? Does using rc-5 resolve your problem?

To add to your opinion that the behaviour for > 16 files selected, I totally concur - it is VERY weird. But the v6 extension didn't experience the same issue (I stepped through the code) and for v5 compiling the Unicode builds seem to have removed the problem. Wait for 5.8.7 final which should be out really really soon (I'll sign it :)) and then you can check if the problem is resolved then.

Joel
 
Unfortunately for me the recent Unicode update on the SVN had no effect on the 16> file issue I still need to make my changes to get it to work.

The reason I was assuming that my issue with 16+ files in version 6 was the same as 5 is that the code I changed to fix it has its equivalent in the version 6 code however testing it right now with beta4 in one case it failed on 243 files and on beta5 I've had it fail on 234 and 500 amongst others. I tested with different files in different locations each resulted in a different number of files giving the same error, even renaming the files seems to result in a different fail point. Kinda weird that the first time I tested it was 17 files on the dot but there you go. It is still possible it is the same error, that windows is insisting on using a string and throwing around GCS_VERB requests instead of just the GCS_HELPTEXT that is currently handled just that for whatever reason its more erratic under version 6.

The Error is Titled: Eraser Shell Extension
The body: The Eraser application could not be started. Ensure that your installation of Eraser is not corrupted: try running the Eraser Setup again to Repair the install.

The reason for the warning about my competency was just in case, just cause I'm commenting on these things doesn't mean I actually understand them. Something along the lines of, a little knowledge being a dangerous thing. Anyway I'll get around to seeing what I'm doing wrong compiling 6 and hopefully be able to provide something slightly more useful.

Okay had a quick look and seems the error in 6 stems from the createprocess line 835 of CTXMenu.cpp which means that the cause of the problem in 6 is that the commandline is too big, if I'm reading the right bit the limit is 32,768. My way of generating files for testing was to take a few files and repeatedly copy them so that doesn't help too much as you get long filenames made up of copy - copy - and so on Not sure of the real world likelihood of this issue.
 
Well I just deleted 198 "New Microsoft Office PowerPoint Presentation.pptx" (and their associated Copy (X) counterparts - my testing regime is the same as yours)

Rein said:
The reason I was assuming that my issue with 16+ files in version 6 was the same as 5 is that the code I changed to fix it has its equivalent in the version 6 code however testing it right now with beta4 in one case it failed on 243 files and on beta5 I've had it fail on 234 and 500 amongst others. I tested with different files in different locations each resulted in a different number of files giving the same error, even renaming the files seems to result in a different fail point. Kinda weird that the first time I tested it was 17 files on the dot but there you go.
Click to expand...
I don't think v6 has your fix. We still check for valid arguments in the function prologue:
Code: 
		//If lpVerb really points to a string, ignore this function call and bail out.
		if (HIWORD(pCmdInfo->lpVerb) != 0)
			return E_INVALIDARG;

		//If the verb index refers to an item outside the bounds of our VerbMenuIndices
		//vector, exit.
		if (LOWORD(pCmdInfo->lpVerb) >= VerbMenuIndices.size())
			return E_INVALIDARG;
I would tend to imagine that the change in behaviour is because of how Explorer stores the file names - they dangerously tend towards the 32,768 char limit (with just some simple multiplication - explaining the various fail points with different file name lengths)

Rein said:
The Error is Titled: Eraser Shell Extension
The body: The Eraser application could not be started. Ensure that your installation of Eraser is not corrupted: try running the Eraser Setup again to Repair the install.
Click to expand...
That is to be expected as part of the 32,768 char limit - command lines can only be shorter than 32,768 characters or else we'll get weird behaviour like this.

Joel
 
You must log in or register to reply here.
Back
Top