List processing bug - v.1.8.0.466

tullik

File Cleaner - Temp dirs bug - v.1.8.0.455

Edit: topic subject changed 29 April 2008

Edit: topic subject changed 5 August 2008

The tool sometimes does not delete all the selected items in the list. The Delete button had to be clicked four times to clear the list in the run shown below. I suspect the issue is probably also in the other file/directory tool results lists.

br0ken

This problem is also present in V 451 & V 455 using registry cleaner

redseujac

Confirmed
.

On has to click several times repeatingly the "remove" button to get removed all selected items in Registry Cleaner.

In other words: you select all the items in the list, click on "remove" and then the cleaner removes some entries and then stops. You have to repeat the action several times to get all listed items removed.

tullik

This bug, which is present in nearly all tools with results lists, wastes a lot of user time. It would be nice if it were fixed in the next release (or so). :) This report is for v.1.8.0.457.

1. The user must click a tool's action button one or more additional times to process the list completely

2. The user must respond to the resulting multiple backup dialogs

3. The user may choose to rescan to confirm the fragmented operation was really successful

4. The multiple backup subdirectories impact the list construction performance of the Backup tool, and result in a larger list for the user to examine

The bug occurs frequently, as shown in these filtered screenshots of the Backup tool (only part of the extra actions show for the Registry Cleaner):

04-29-2008_20-11-26.jpg

04-29-2008_20-14-26.jpg

jv16

This seems like a difficult problem to solve as I haven't been able to reproduce it. Still, I have a feeling where the problem may be, so I did some changes and I hope the problem could be fixed in the next released version. The next released will be out in next week.

tullik

The problem still occurs with, for example, File Cleaner in v.1.8.0.460. The File Cleaner list showed 41 files. The first "Delete" click got 33 files; the second click got the remaining 8.

redseujac has reported elsewhere that the problem is also still in the Registry Cleaner raw list.

tullik

While attempting to get a new format debug log for this issue in File Cleaner, I was stopped by an Application Hang .

After that is fixed, I will try again.

redseujac

Sorry, we encountered an error while displaying this content. If you're a user, please try again later. If you're an administrator, take a look in your Flarum log files for more information.

jv16

I am very happy to finally be able to say this: I was able to reproduce the problem and fix it!

The problem was one of the nastiest ones to fix: a race situation. This occurs when two parts of the program process data at the same time and the outcome debends on which of the two parts working at the same time finishes first, if the first one is faster everything works fine, but if in some cases (i.e. some systems) the second part always comes out faster the problem occurs.

I had to create a directory with a few gigabytes of test data and delete them in order to really see the problem in action and finally fix it. While doing it, I also found a small bug that could in some cases crash the PowerTools's File Tool, that's also now fixed.

So, thank you all for reporting this problem, the next version of PowerTools with this problem fixed (from all tools) will be released probably in next week.

tullik

Hurrah!

tullik

V.1.8.0.467

To test this for File Cleaner (FC), I restored 17 backups from 8 FC runs. Each of those FC runs formerly took at least 2 passes to clear the list; one took 3 passes. Altogether, 214 files were restored and showed up on the FC Temp dirs run.

I selected All and clicked Delete. It still took two passes to clear the list. So I restored those two backups and did it again. That time, it cleared the list with only one click on the Delete button.

I did it once again. It still cleared the list with only one click on the Delete button.

Twenty-four hours later, I did it four more times. There were 218 files on the list for each run. Three times, the list cleared with one click on the Delete button. Once, it took two clicks. That time, the tool had not finished with the delayed filling in of column information (the three date columns). Perhaps that routine is not properly accounted for in the race condition correction ...

History: The older FC backups still on my system show that 6 (28%) cleared with one pass, 12 took two passes, and 3 took more than two passes.

Conclusion: In the multiclick runs, the wrong parts of the program won the race. In the single click runs, the right parts of the program won the race. The situation likely has been improved -- in v.1.8.0.467, 71% cleared with one pass. Seven runs is a small sample, but I'll mark the issue "Partially fixed" pending feedback from other users.

Note: I did not perform a Registry Cleaner test of this issue.

tullik

V.1.8.0.467

This describes tests of this issue for Registry Cleaner (RC). All runs used Quick select: Normal and the raw list.

The first run cleared the registry of "errors." There were 18 lines. They cleared with only one click on the Delete button.

I then did 18 restores or custom restores of "safe" items in old backups, then ran Registry Cleaner. The list had 332 lines. They cleared with one click on the Delete button.

I then restored that backup, ran Registry Cleaner, and cleared the 332 line list. I did this 5 times. Each time, the list cleared with only one click on the Delete button.

History: The older RC backups still on my system show that 8 (62%) cleared with one pass, 4 took two passes, and 1 took three passes.

Conclusion: The situation likely has been completely fixed for RC since the list cleared with only one click on the Delete button in 100% of the 1+1+5=7 tests. For the File tools with selectable columns, it seems to be only partially fixed (see previous post).

Note: I seldom do "Fix" with the Registry Cleaner. The way I use my systems, that would generally be pointless.

tullik

v.1.8.0.468 (probably equal to v.1.8.0.467 for File Cleaner)

I performed the File Cleaner (FC) test as in a prior post above, now with 240 files in the temp directories.

The first two times, the list cleared with one click. The next two times, it took two clicks. It did not always make a difference whether or not the delayed column populating was complete.

The fifth time, the tool window did not do anything when I clicked its Start button. Closing and restarting the tool did not help.

After exiting and restarting PT, FC worked again, but it took two clicks to clear the list.

It seems there is still some sort of race condition in the file tool, but there is probably some improvement. At least it has not yet taken three or four clicks to clear the list.

redseujac

I tested in Registry Cleaner...

RC found 325 erroneous entries (Raw list). Selected them all. Clicked "delete" button. All entries removed by one single click.

So, I accept the issue is fixed in version 468.

tullik

redseujac wrote
I tested in Registry Cleaner...

RC found 325 erroneous entries (Raw list). Selected them all. Clicked "delete" button. All entries removed by one single click.

So, I accept the issue is fixed in version 468.

Time will tell. My sample of eleven File Cleaner runs had 55% with one click and 45% with two clicks. I'll check in a few weeks to see what the Backup tool shows.

It is (I hope) 100% fixed in Registry Cleaner, as I said earlier above, with a sample of seven runs.

tullik

@ jv16

It's worth noting that each time it took two File Cleaner clicks to clear the list, something unusual happened.

Namely, the "Done" message did not appear for the first click. It did appear for the second click, but only accounted for the second click files cleared.

The backups for each of the two clicks appear to be OK (they add up to the correct size).

tullik

v.1.8.0.472

I restored two File Cleaner "Temp dirs" backups. One contained 240 files and the other contained 102 files. The next File Cleaner run showed 333 lines -- likely some files had the same name.

Select all-->Delete left 58 lines on the list; there was no "finished" message; the backup contains 305 files.

Clicking Delete again dropped the 58 lines from the list; there was a "finished" message; the backup contains 28 files (305+28=333).

I restored the backup, ran File Cleaner again, got a list with 333 lines, but waited until the column data (size and three dates) was completely filled in before I clicked Delete. The list was completely cleared; the backup contains 333 files.

I did this four more times and got the same correct result the first three times. The fourth time, Select all-->Delete left 30 lines on the list; there was no "finished" message; the backup contains 303 files.

Clicking Delete again dropped the 30 lines from the list; there was a "finished" message; the backup contains 30 files (303+30=333).

Apparently there is still a remaining race condition which sometimes leaves lines on the list and causes the "finished" message to be omitted.

For the File tools, the issue remains "Partially fixed" in v.1.8.0.472.

tullik

v.1.8.0.472

In debug mode, I repeated the above described test with the 333 files.

The first time, File Cleaner cleared the list correctly with one click on on the Delete button, and the backup showed 333 files.

The second time, while the list was clearing:

*** A message, "Invalid pointer operation," appeared in the message box

*** Immediately thereafter, a Windows APPCRASH pop-up occurred

*** All PT windows went away when I clicked the message box once

*** The backup contained just 230 files

The logs from both times are in the attachment.

File Cleaner (2 runs).zip