Eraser Freezes while erasing

[aircraft]

Hello.

I use the latest downloadable version of Eraser. I'd really love to use and have such a program but it doesn't work well.

No matter how I erase files(either right-click->erase or erase whole folder) it freezes after an average of 5 files. No matter how long I've waited, it didn't work on. If I click on the stop button, it says "Terminating...". At this stage it usually crashes my explorer.exe. Maybe interesting: i used it for media files such as mp3, mpg etc.

If I reboot and take a look at the last file, that should be erased, when eraser freezed, i recognize, that it has a size of about 4-14 GB(!).

My OS: WinXP (SP2)

Thanks a lot.

[Joel]

Aircraft, I'm having the same problem. I'm running XP Pro SP2. I don't seem to have the freeze up problem if I erase 1 Word file at a time, however more times than not if I attempt to erase 10 files or more simultaneously Eraser freezes.

At Eraser freeze up I check my hard disk and free space goes down from 17+GB to less than 7GB. When I attempt to stop Eraser, it stops but the dialog box remains up and my computer slows almost to a stop. I use Task Manager to stop the process but the dialog box still remains up. Finally I use Task Manager to end My Documents since I can't simply click it to stop it. Finally the Eraser dialog box is gone.

I check free space and it remains down 10+GB.

I reopen My Document, find the file Eraser freezed on and try to erase again. The last time I did this Eraser indicated "estimated minutes" =58! I'm talking about a 200kb Word file!

I leave the computer and wait the 58 minutes and the file is finally erased. Here is the Eraser log file:
Statistics:
Erased area = 10585 MB
Cluster tips = 0 bytes
Data written = 74095 MB
Write time = 2856.22 s
Write speed = 26564 kB/s

After all this I check free space and my hard disk is back up to 17+GB.

I can not continue to use Eraser with this continual glitch. I even uninstalled Eraser and reinstalled it to no avail.

I would very much appreciate any help or insight anyone can give here.
Thanks.

[Joel]

I see this sometimes too - but I haven't found a good reproducible case. Can you report the filesize etc? It may be of help.

[Joel]

Thanks Joel.

Eraser stalls in mid overwrite on multiple files only. For example, I highlight 10 Word files ranging in size from 80-400kb. This stall has occured several times on both Word and photo files. If I recall correctly, it happens toward the end of the erase process. In other words, Eraser runs for a while and 9 of the 10 files seem to be overwritten successfully, then it stalls on the final file. I'm not 100% sure it is always the final file though.

I have not tried to duplicate the freeze up because it leaves my computer useless for an hour or so. I have used it lately only on single files without a problem. This, however, is a pain in the "A" since it is very time consuming.

If I misunderstood your request or you need additional info, please let me know.

[Joel]

I've noticed this too, I've usually just put it down to just too much ram being used by other programs..so I reboot and try again. If I am in a rush and don't want to take the extra time it takes to reboot I bringup the task manager and kill eraser.exe and go to another erasing program(which I used before I started using Eraser) like East-Tec Eraser 2006 (which I bought in 2005) or Tune ups shredder.

[Joel]

Carver, my fear is that a file or files that Eraser did not successfully overwrite remain on my computer unknown to me. That totally defeats the purpose of Eraser.

[Joel]

Sorry for the additional workload joel :)

The bug drove me insane to pinpoint when/where it was occurring, but I'm glad my frustration can at least give you a looking point.

I might also want to point out that on Compressed NTFS files for XP, Eraser seems to make multiple gutmann passes per file, and this behaviour escapes me. (E.g, it will count one to thirty five several times per compressed file) and it takes much, much longer for a compressed file than a non compressed.

Might I suggest not following the laws of the file system for a compressed file delete and instead writing directly to the sectors it actually occupies? I have a feeling Windows is uncompressing/recompressing the overwrite data which is causing weird things to occur; though whether or not this is entirely related to the occasional hang issue is unknown.

It might be worth mentioning that my workaround for this bug right now is to use windows search in the folder you wish to delete, search for all files, and then order the results by attributes (so that the compressed files are next to each other) and then highlight the compressed files, right-click, and use eraser to get rid of them. Afterwards, use eraser as normal for the remainder of the files.

It's not an elegant workaround, but it's the best I've found and it sure beats hitting "stop" and waiting for eraser to make a 5gb file every 5 files or so.

Cheers.

[Joel]

We already are working around NTFS and writing to the disk directly. This is what is causing Access Denied errors for me under Vista.

Joel

[Joel]

This is seriously annoying.

For Vista, you're not going to be able to erase the file unless you lock the WHOLE drive. This would mean that the file will not be erasable if the drive is your system drive. So I wonder if I'll have to drop support for this feature in Vista? And possibly XP too since it is corrupting drives?

Unless other people have ways around it?

Joel

[Joel]

5.x problem.

[annoyed1234]

My observations on the problem (observed over at least two years with 5.8.7 and at least 2 older versions I forgot which, on NTFS only so far as I do not erase camera media and all my sticks etc are ntfs, XP SP3 and SP2):

• The 'hang' is caused by "something" expanding a small file to huge proportions. In my case, if I do not hard kill eraser, the file in question will grow to *exactly* 128GB (GB=2^{30). Thus, unchecked, eraser would grow the file to 128G (about 0.5h) then erase those (<=7 hours), then exit successfully.}

• Stopping eraser using its cancel button or Killing eraser (eraserl if erasing recycle bin, otherwise the parent explorer) with sysinternals process explorer in the first of the two phases decribed above will, unless harder methods are taken, finish expanding the file in question to 128G or until the disk is full (within a few MB if NTFS), then exit and leave the expanded file. If the file in question was a recycle bin file, it will have disappeared from explorer's view of the recycle bin but not be exempt from further eraser attempts. The file will be visible to a command prompt using attrib.

• Whether the bug is perceived as a hang or not depends on the drive/controller/drivers. While I can play a 3D game (which is installed on a distinct drive using a separate controller) without noticeable slowdown while the bug is in effect, someone erasing stuff on his system drive attached using the Microsoft default ATAPI driver will probably observe a full-blown freeze.

• The host process will IMHO -my best guess- *seem* unkillable by procexp because a close handle will be issued and the handle will not close before the file expansion is done, which will take the large amount of resources because it is zeroed out on disk. At this point eraser is no longer really involved, I think the kernel just has a few million (or one large) IRP's on the IO stack which it refuses to abort in response to the kill of the originator. Once the IRP stack is emptied, the kill is finally honored.

• Dismounting the drive in question or cutting power to the drive or pulling the data cable will cause the pending kill as above to be honored within 1-2 seconds, corroborating my guess.

• The bug either trigger immediately upon opening a new file for erasure or it does not and the file is erased properly.

• My subjective impression is that having small files in the target list increases the probability of triggering the bug, above the obvious effect that smaller files means more "open file" steps. On the other hand, I think erasing a long file list by dividing it manually into smaller portions has the exact same overall risk as doing it in one block.

• All things considered, this might be due to an erroneous file size being reported and eraser starting to erase from the "end" of the file??? If so, double checking the file size might help - as in "erase first cluster, close file, recheck size, continue".

• "working around NTFS and writing to the disk directly" - IMHO unnecesary. There's enough support in the normal Win32 API as is. To erase compressed files without going through the compression filter, you just need a few flags on the CreateFile? call as far as I remember, and you do not even need admin rights, ""just"" backup/restore rights. Similarly for sparse files, reparse points etc - which I would guess you already handle properly.

I hope this might trigger some "aha" effect, keep up the good work. Sorry for not checking my suspicions against the sources myself.