Eraser 6.0.6.1743 - First Last 16KB threshhold addressed in change 1745 is 28kB rather than 32kB

[bOoGiEwOoGiE]

Regarding Eraser 6.0.6.1743

All input files were created with fsutil at command line in Windows 7 Ultimate x64. The install is clean except for some video and audio drivers and TrueCrypt?. The results were obtained by emptying out the AppData? folder completely, making sure Eraser.exe was not running, and calling the task from the GUI interface. This build has a habit of opening that way but not doing any work. And whether it did work or not, it was capable of duplicating its notification area icon and either that twin would go away or it would not. I included a copy of my fsutil creations just in case you would like to use them someday. All results are located at  http://cmbl.netai.net/eraser/results.rar

My main set of observations was that when I would use default file erasure method FL16k and a one pass pseudorandom or custom (alphanumeric), it would erase files of any size properly. When I switched the FL16k to any preset method that used more than one pass or a 2 pass 00h, the largest file that would erase properly is 28kB exactly 28,672 bytes in length. The files with a length of 28,673 and above would produce the result shown by {test28k+ - result.fil} and would not destroy the file name. Another interesting side effect of the 28k+1 test is that the result is 32kB exactly 32768, adding 4095B to the weight and the 32k-ish test would add 4034B.

The error that came up every time was:
The Completed property of the Progress Manager cannot exceed the total work units for the task.
Parameter name: value
Actual value was 49152.

This value did not change.

[bOoGiEwOoGiE]

Part of  http://cmbl.netai.net/eraser/results.rar

[bOoGiEwOoGiE]

http://eraser.heidi.ie/trac/changeset/1745#file1

[bOoGiEwOoGiE]

117 if (strm.Length <= dataSize * 1.75)

or

117 if (strm.Length < 28673)

I am a new poster so I don't know if strm and dataSize are defined in Bytes or bits and if it's Bytes is dataSize=16384? But, I am now scouring your resources to find the source code so I am more informed and can actually post accurate numbers when i suggest code changes. :)

I have used eraser for a long time and with my transition to Win7 x64 I was affected by a bug that smashed a partition. I thank you all for your effort and I hope that my ticket improves the product.

[Joel]

Replying to bOoGiEwOoGiE:

Regarding Eraser 6.0.6.1743

My main set of observations was that when I would use default file erasure method FL16k and a one pass pseudorandom or custom (alphanumeric), it would erase files of any size properly. When I switched the FL16k to any preset method that used more than one pass or a 2 pass 00h, the largest file that would erase properly is 28kB exactly 28,672 bytes in length.

What is the file system you are using on that disk, as well as the cluster size of the file system?

The files with a length of 28,673 and above would produce the result shown by {test28k+ - result.fil} and would not destroy the file name.

I do believe this is just the erasure failing?

Another interesting side effect of the 28k+1 test is that the result is 32kB exactly 32768, adding 4095B to the weight and the 32k-ish test would add 4034B.

The file system you are using influences this: files are erased as-is first if it is smaller than one MFT record in the case of NTFS, then extended to wrap around the cluster so that cluster tips are also erased. If your cluster size is 4096 bytes, this may explain the behaviour.

The error that came up every time was:
The Completed property of the Progress Manager cannot exceed the total work units for the task.
Parameter name: value
Actual value was 49152.

This value did not change.

I've not got time to test the samples in the provided file (thanks!) But I've got a fix in r1756. Test it when the build is built and let me know if it's fixed.

[Joel]

Replying to bOoGiEwOoGiE:

117 if (strm.Length <= dataSize * 1.75)
or
117 if (strm.Length < 28673)

I am a new poster so I don't know if strm and dataSize are defined in Bytes or bits and if it's Bytes is dataSize=16384? But, I am now scouring your resources to find the source code so I am more informed and can actually post accurate numbers when i suggest code changes. :)

The code multiplies the maximum data length to be erased by 2, not 1.75. And it's in bytes...

I have used eraser for a long time and with my transition to Win7 x64 I was affected by a bug that smashed a partition. I thank you all for your effort and I hope that my ticket improves the product.

How did it destroy the partition? Which version?

[bOoGiEwOoGiE]

Thank you for your reply and your patience Joel. My apologies for possibly wasting your time but you did help me understand some things better. I will answer your questions first.

I am using NTFS with 4096B clusters on all partitions. Thank you for making me aware of cluster tips again :)

This partition that I described as "destroyed" was simply a MFT corruption from erasing a compressed or sparse file which you had already addressed. Data was 100% recovered. It was my fault because I was using a 5.x in Windows 7 and I can not remember the exact build. I should have updated my software!

You said "I do believe this is just the erasure failing?" After your reply I thought a bit more on my ticket and realized that I based the issue on a build that is not current. My apologies again. I define a proper erasure as destruction of data and removal of the file record and name from the MFT. In the case of the failures I described and as evidenced by the input and output I provided, I can not judge if the data was properly processed without tearing out my hard drive and inspecting the platters with forensic means. However, I do know that the input files were made of characters that showed in a reader as spaces and the failure output (the fact that I still had a file on MFT to open in my reader) was made of junk characters throughout, suggesting that some processing had taken place. To what degree I cannot tell.

The issue that I described should have been pared down to this and nothing more: in 6.0.6.1743, the FL16k default erasure method with plugin set to any one pass method will affect a "proper erasure" no matter what the file size. If the plugin is set to any method that uses more than one pass, the FL16k default erasure method will affect the data to an unspecified degree, but leave the record in MFT *if* the file size is larger than 28k exactly (28672) and will return the error in my original ticket.
Before posting my ticket, I checked code revisions and found an if test for the size of the file. I found that your test had 2 options, and my concern was that sending a data stream between 28k and 32k to the <32k option would create the error. Unfortunately I do not understand what the 2 options do, and blindly suggested multiplying your dataSize by 1.75 to represent exactly 28672. I did not take that into account when posting the ticket. Again, my apologies.

I look forward to your next release and I would like to know how to make myself more aware of the inner workings of the program by study. I realize you are not paid for what you do and I would like to help purely out of my concern for data security.

And I promise I will not go off half-cocked again :)

[Joel]

Did the later nightly build fix your problem?

[trac-robot]

This ticket was closed automatically by the system. It was previously set to a Pending status and hasn't been updated within 14 days.