Pass the entire XmlReader? to the targets for deserialization since passing a subtree would cause the graph to not load correctly (the parent XmlReader? will not reach the end element, even when the subtree has been read to the end). This prevents us from deserializing multiple items properly if the subitem is an empty element.

Make the LogSink? a base class (LogSinkBase?) and implement a normal LogSink? (API compatible with the old LogSink?) and a new LazyLogSink? class which will load a log from disk as required.
As a result of this change, Task will have two WriteXml? functions: The default will continue to generate the same code; the new overload will place references to logs if the logs are larger than a certain threshold. This is to optimize the task list for size when loading/unloading.

Implement a different ReadXml? overload that allows derived classes to instruct base classes whether to advance the XML Reader pointer forward. This allows us to read attributes of the same element.
Also fixed the ordering of saving targets to disk.

*Properly* follow the contract specified in IXmlSerializable.ReadXml?: the reader is placed at the start of our element, and our ReadXml? implementation must read the entire element to the end of the element before returning.

Follow the contract specified in IXmlSerializable.ReadXml?: the reader is placed one before the start of our element, and our ReadXml? implementation must read the entire element to the end of the element.

Follow the contract specified in IXmlSerializable.ReadXml?: the reader is placed one before the start of our element, and our ReadXml? implementation must read the entire element to the end of the element.
Also, use the O format when storing DateTime? values in the XML file. It has greater precision than the normal ToString?() call.

Added a priority list for the primary and secondary hash algorithms. Favour the Crypto Next Gen APIs first, since they have higher speed on Vista+, fallback to the CryptoAPI implementations if they can't be created, and finally use the Managed implementations if the above two fail.

Removed the capability for switchable algorithms at runtime, and changed the default pool mixing function to SHA-1 since under FIPS compliance mode on Windows XP the SHA-2 family of hashes are not available. RIPEMD-160 is likewise not available. As such, under FIPS compliance mode, we will only use SHA-1, even on later OSes, and make primer mixing with RIPEMD-160 unavailable.

The sleep time between polls is now variable between 2 and 5 seconds. The previous one tended to pick the same amounts of time since it would effectively make one loop double the time it took to gather entropy from all entropy sources.

Use null as the parameters for the Container and Provider parameters instead of the empty string, since that is what MSDN documentation says we should specify if we want defaults. In addition, specify CRYPT_VERIFYCONTEXT for accounts which do not have a persistent key container (e.g. Guest accounts).

Addresses #406: Not able to acquire a Cryptographic Service Provider on startup

Behavioural change: Removed the capability for switchable algorithms at runtime, and changed the default pool mixing function to SHA-1 since under FIPS compliance mode on Windows XP the SHA-2 family of hashes are not available. RIPEMD-160 is likewise not available. As such, under FIPS compliance mode, we will only use SHA-1, even on later OSes, and make primer mixing with RIPEMD-160 unavailable.

Addresses #406. Eraser 6.2 will require a different fix; which would be to use proper fallback mechanisms (with the using the Crypto Next Gen APIs, which are said to be 10% faster)

Backport from Eraser trunk: Better reparse point handling for Eraser 6.0 (​https://eraser.heidi.ie/forum/viewtopic.php?f=2&t=8684&p=25969#p25966)r2561: Part 2 fix for ​https://eraser.heidi.ie/forum/viewtopic.php?f=2&t=8684&p=25969#p25966 since erasing the actual reparse point would cause Eraser to crash if the reparse point references an invalid target.r2560: Supplements r2549: Resolve reparse points only for as long as the reparse point we are referring to exists; otherwise fall back to volume name resolution.r2559: We should only check for FileSystemInfos? in the directory being erased if the directory is not a symbolic link. Otherwise, the check is meaningless.r2558: When we are setting file times for reparse points, we should fall back to setting the file times for the reparse point itself if we cannot set it on the target of the reparse point (such as if the reparse point points to an invalid object.)

When we are setting file times for reparse points, we should fall back to setting the file times for the reparse point itself if we cannot set it on the target of the reparse point (such as if the reparse point points to an invalid object.)

Forward-port from Eraser 6.0: When we are dereferencing a reparse point, we only need FILE_READ_ATTRIBUTES | FILE_READ_EA access. Do not request GENERIC_READ access since for reduced permissions links (e.g. the junctions in the Vista+ User Profile folder) those permissions are not granted at the directory level (soi even administrators can't have those rights!)

When we are dereferencing a reparse point, we only need FILE_READ_ATTRIBUTES | FILE_READ_EA access. Do not request GENERIC_READ access since for reduced permissions links (e.g. the junctions in the Vista+ User Profile folder) those permissions are not granted at the directory level (soi even administrators can't have those rights!)

Tasks were not being cleared from the task list upon successful completion because they were reset to Manually executed tasks before returning to the Executor. This scheduling ability should be dealt with in the Executor and not the Task. Therefore, the Task Completion event will still have the schedule of the initial configuration, and not after the schedule has been reset to Manual. This allows context menu tasks which completed successfully to be cleared automatically.

Backport from trunk: Fix a misnomer: when Eraser is running, and a new task is added, it is possible that the task was added remotely (e.g. via shell context menu) and if the schedule is Run Now, the task could already be running when we receive the event. In those situations, do not reset the task status to Queued for Execution (which we do for new tasks)

Fix a misnomer: when Eraser is running, and a new task is added, it is possible that the task was added remotely (e.g. via shell context menu) and if the schedule is Run Now, the task could already be running when we receive the event. In those situations, do not reset the task status to Queued for Execution (which we do for new tasks)

Move the call to Application.EnableVisualStyles? to the start of the program so that if a console window creates a WinForm?, it would have the correct behaviour.
Fixing this bug also fixes the drawing problems associated with the display of the shell erase confirmation dialog.