[v6] Eraser Architecture and Design decisions

Not open for further replies.


Active Member
The purpose of this post
Eraser is an open source project. It is therefore appropriate that the programming team should explain to users the reasons for a number of the design decisions that lie behind the complete re-write of the application which was undertaken for Eraser 6, and also respond to some of the criticisms that have been made of those decisions, so that users can make informed choices about whether and how they use the application. Each of the major issues that has been raised on this forum is considered under a separate heading.

Eraser 6 needs the .NET framework
Eraser 5 was written in C++, since that was the predominant language at the point of writing. It started as a simple project, and grew with time. Things have changed one decade on, and Eraser is very short on manpower as committed volunteers with the necessary skills are few and far between. .NET was used in the hope that more programmers possess the required skill and proficiency.

This was proven wrong, but nonetheless it is too late and too expensive to undo this decision. In any case, the disadvantages of .NET have not proved to be as great as some critics have claimed.

Apart from memory and speed, what other complaints can be made about the .NET framework? 5 years ago, memory and speed would have been valid considerations. Since then, the .NET framework has improved by leaps and bounds: RAM requirements for pure .NET apps are as low as, if not lower than, for native applications - the native application would require at least the C and C++ runtime to be loaded, which is analogous to the .NET framework libraries in size and complexity. The runtime speed of managed applications today is roughly equal to that of native applications.

Eraser 6 has to run in the background all the time to work properly using significant amounts of RAM. Eraser 5 ran perfectly without a background service.
If RAM usage is a problem, the new architecture has the significant advantage that, because that since memory is .NET managed under cases of high memory pressure memory is freed. The program no longer manages memory and hence memory cannot be "leaked."

Eraser 5 ran perfectly without background services, yes, but that was because it was developed without the concept of services (back in the old days of 9x) and also because then most users always ran with administrator permissions. This simply isn't true today with Vista and 7 both implementing UAC. Services will be fully implemented in 6.2 (schedule permitting) and that's when the real benefits will be realised.

Running Eraser as a background service also brings other benefits. The disk subsystem was always seen as the bottleneck in any erase and the process allowed scheduling of the tasks so they do not stress the disks since all erasures can be consolidated and queued. In addition, it also allowed a very powerful scheduling system which is vastly more flexible than that found in Eraser 5.

Lastly, background running was implemented because most erasure tasks should be done in the background. The user would press delete and let Explorer delete files and proceed with his other work; Eraser should be operating on the same principle. We hope you'll be patient to wait for that: it may be a long wait, but we believe it's definitely worth it. The improvements you already see in 6.0 are only the tip of the iceberg. Take a look at our Trac Task List to see the planned improvements: without implementing changes in the code which rewriting the whole application from scratch allowed for, those tasks could not possibly have been implemented, due to complexity constraints.

The system tray icon is really unnecessary and brings no real functionality gain.
If the icon were removed, there would be no guaranteed way to access the Eraser GUI. v6 is a bridge between the in-process Erasures in v5 and the Service-based erasures in v6.2 (or later, depending on the programming schedule). The animation when an erasure is in progress serves to inform you when you are running an erasure.

The Feedback bubble informing users about task completions and statuses is just terrible and is a real nuisance which cannot be removed even in the settings.
Notification balloons are supposed to be unobtrusive especially for people who have carried on with other tasks. If you compare this to the modal dialog Eraser 5 showed while erasing from the context menu, it is significantly less annoying.

Eraser 5 had a portable version. Eraser 6 does not.
Remember that Eraser 5 only had a portable version only late in the 5.8 series. The portable versions aren't as easy to develop as it increases the number of development scenarios, but this will definitely be considered for future versions.

When I want to erase a file, I have to do two steps now. First right-click on the file, then choose "Eraser" and then "Erase". At version 5 it was only one step for erasing files.
The context menu issue is really personal.Some people would rather have it uncluttered (they have posted here over the months prior to the development of v6); others want fewer clicks. It's not going to be possible to satisfy both camps, unfortunately. For users clamouring for customisable context menus, we'll have to turn your requests down for the moment. The current implementation doesn't do anything less than what you're proposing and customisation only serves to add more code that needs maintenance. We may return to your proposals later when higher priority bugs have been fixed.

Version 6 restricted options and removed functionality. An upgrade is supposed to add functions.
v6 has these new features:
  • Unicode Support from the onset
  • Fully localisable User Interface
  • Customisable plausible deniability feature
  • Flexible and highly customisable scheduler
  • The ability to group tasks together to be run as one unit, allowing for complex tasks to be crafted
  • The ability to author more complex custom erasure methods
  • The ability to force open files to be closed for erasure, without needing a restart
  • Better error reporting (in terms of logging) as errors in v5 usually go unnoticed
  • Better (we admit it's not yet perfect) UAC support

In addition, one case of severe file system corruption has been fixed (v5 had a few nasty filesystem corruption bugs, especially when erasing sparse, compressed or encrypted files.)

v6 has only removed two features: Secure Move (for reasons described above) and the Modal Progress dialog in the Shell extension. Secure Move is being implemented in 6.2, and the progress dialog following Vista/7's modeless progress dialog is being planned.

The confirmation box with user-selectable overwrite passes which may differ from case-to-case has been done away with. At least allow an option for those users who prefer to have it. This also served as a warning in case a user made a mistake when clicking on Eraser right-click option; currently there is none!
This will be dealt with in 6.2. However, the design of 6.0 is still sound as "defaults" are there for a reason. If the information that one deals with warrants 35-pass erasures all the time, you should be setting that as a default. If you think that you just want to get rid of file headers, use the First/Last 16KB erasure method. The idea is pick one default that works for all the files you deal with. Defaults should be chosen by the you (you have the ability to!) and adhered to for the majority of use cases (hence "Defaults")

The context menu option "Eraser Secure Move" has now been discarded
This will be implemented in 6.2, and will be supplemented with an "Eraser Secure Paste" command, so users can just cut, and Secure Paste.

The architecture of 6.0 didn't allow this implementation, and when I realised this was missing it was too late in the development cycle to make such a major change. The alternative for 6.0 users is to copy the file, then erase the copy you don't want.

Windows already has a job scheduler. If I schedule a job, use that, or just complain that the tray icon and persistence is disabled and then gray out scheduling of jobs.
XP's scheduler is too simplistic. Vista's is more like what Eraser has however it does not deal with erasures done in parallel. In any case, for the reasons already given, removing the built-in scheduler would not remove the need for a running process.

It would have been a much better idea to keep Eraser as it was in version 5 and from there make improvements. Version 6 is such a big mess.
To us as developers of Eraser, v5 is a nightmare to maintain. Retaining the old code base would have severely constrained our ability to meet current and future user needs. Inevitably, there will be differing views both on the program architecture and on the UI, but the Eraser Team believes that Eraser 6.x provides a much better and more secure foundation for future developments than Eraser 5 could ever have done.

If you have any other comments, post to the Opinions thread.
Not open for further replies.