What should the Eraser log look like

[DavidHB]

This discussion started with an aside to this topic on the Support forum.

I wrote:

It would be nice to go back to Eraser 5 at least to the extent that the logs tell you a lot less of what Eraser cannot do and at least something of what it is doing. Perhaps a log referring to each element of the task and saying whether it could be completed provides a sensible structure. For instance:

Starting Task Erase Free space on Drive C:
Erasing cluster tips
Eraser erased cluster tips, but could not access 15,467 protected or locked files
Erasing free space on Drive C:
147GB of free space erased; erasure completed
Erasing unused MFT entries
233 unused MFT entries erased
Task completed

or

Starting unnamed task initiated from the context menu
Files in folder ZZZ1234 deleted. Folder deleted.
File ABC5678.nnn deleted
File DEF9012.mmm deleted
Task completed

Does this make sense? If so, I'll start a task in Trac (unless there's one there already).

Joel responded:

On your suggestion, yes it is possible. But I still think it will be lost in all the other messages. Messages like these cannot be given a higher priority level than the cannot erase cluster tips for file XYZ messages: it just wouldn't make sense. One Informational entry at the end of the erase can be made, but if the user filters the log to Warnings and above, he won't see it. I think there was such a request before, but I don't know how to get about implementing it...

This exchange gets to the heart of the issue I was trying to raise. The current Eraser logging approach is that only (hierarchically categorised) exceptions are logged; if something works, there is no log entry. This is in marked contrast to other utility applications, such as CCleaner, Recuva and any registry cleaner I can think of, which major on telling the user what they are going to do or have done and report exceptions in that context.

A number of users, sometimes citing Eraser 5 which is not necessarily the best role model, have asked for a logging system that reports the specifics of tasks completed, for example for use in security-conscious environments where a paper report of drive erasing is required. My suggested report layout was intended to describe the bones of such an approach. There is no thought that activity logging should fit into the hierarchy of exception reports; by definition, activity completed correctly is not an exception. The thought is that the log should always provide a summary of activity completed, with exceptions reported, as now, in accordance with the user preference for the level of exception to be reported. To make logs less bloated, anything that cannot be prevented (e.g non-erasure of cluster tips of system files) should be categorised as 'information' and, by default, reporting of individual 'information' events should be suppressed, though my suggestion is that a total of such events should be provided.

How major a task would it be to develop the logging system in this way?

David

[Joel]

I've made a new ticket.

Perhaps we can have a new logging level called Progress, and make it more important than informational messages, but less important than warning messages?

The logging system is quite extensible, so I'm not too concerned. This would not be as large a rewrite as, say, the plugins code rewrite or the service rewrite.

[DavidHB]

I think your suggestion would probably work, and if you are comfortable with it in programming terms, that is the main thing.

I should make it clear that I see progress reporting as happening in very summary form (not every separate file erase logged as in Eraser 5, though that might be a user option). Essentially, the log should record the task description as specified in the schedule and then state that the task was completed or not, with exception reports giving the detail of what was not completed. The slight exception to this is in relation to free space erasing, where, taking a leaf out of CCleaner's book, I would separately report cluster tip, free space, and MFT erasing. I might also give users the opportunity not to log information events, so as to keep any text output down to manageable size.

We also ought to consider the interaction of this kind of logging with the logic of whether the task in question remains in the schedule. I assume that, if the task is not due to be saved, the existence of only 'Information' or 'Progress' entries in the log would not trigger task saving. However, a user might initiate a task from the context menu or by drag and drop and want to look at the log after completion. I think that the easiest thing here is to have a 'Save Task' tick box either on the confirmation dialog or on the task creation/edit dialog. The box would be set in accordance with Eraser's normal logic (e.g. if the task was initiated from the context menu and the user setting was not to save such tasks, the box would not be ticked), but the user would then be able to override the default.

Incidentally, when the user selects 'Options' from the confirmation dialog, the 'Add Data' dialog that then appears is empty. If only to reduce confusion, should it not specify the data already identified via the context menu or drag and drop?

David

[Joel]

It's a bug in the .NET 4 builds: when we open the Task Properties Dialog and there are tasks already in the task, it's not shown.

I've rewritten the plugin architecture and now I'm grappling with progress notifications for erasures. Once that's done, the new plugin architecture will be merged back to trunk (with the associated instability) before I work on fixing other things.

[DavidHB]

Thanks, understood; I discovered after posting my last that it worked as I suggested in the .NET 3.5 builds. I'm keeping Build 2284 running on my main machine, so that I can compare it if necessary with 2442 on my reserve machine. I probably ought to put 6.0.9 on the laptop ...

And it's taken as read that the architectural and infrastructure stuff you are doing has priority, because everything else clearly depends on it. So, as this has to wait a bit, I'm adding a reference to this thread to the Trac task.

David

[DavidHB]

@Joel

Now that Build 2615 demonstrates significant progress in implementing the XML-based Task List and logging, is there any further thought on the timing of changes to the content of logs?

David

[Joel]

I think I'll kinda complete tasks a bit at a time. Before I implement this, I'd like to make Eraser support >255 character path names and other ways of addressing files. Then it would be allowing remote communication between client/service (but not necessarily implementing Eraser as a service yet) then I'll see what next to implement.

If this is in Trac I don't think I'll miss this out

[DavidHB]

If this is in Trac I don't think I'll miss this out

Thanks; I'm sure #417 is now a happy Trac ticket ...

David