Search results

Cluster tips are the ends of files which have not been deleted. In your case, since you've already deleted the file, erasing the unused disk space (even without cluster tips) should be what you're looking for. Unless you're so paranoid that you're worried the file you are trying so hard to get...

Hmm. If you manage to come up with a list of steps which could reproduce the problem, let me know. I'll look into it. I've not had that problem (and Eraser 6.0 has been out for a while... by now.)

Sorry for the late reply, but I'm sure by now it would have completed. :) External drives are limited by the connection between it and the computer. If it's USB 2, I'd expect it to take approximately 6-10 times longer than if the drive were connected to your computer. If it were USB 3...

You can get the offline .NET installer (50+MB, from Microsoft) and install it first; following which the Eraser installer will not re-install .NET on that computer.

Sorry for the delay. I'm going through the list of threads one at a time. What does the log say?

I agree with you. Hence I believe that's why Eraser 6.2 has its behaviour changed. However, it is generally bad practice to change behaviours like this in the middle of a release cycle, which is also why I want to find out how this behaviour got in (and how there's a documentation discrepancy)...

Is this it?

Which version of the installer is this?

Sorry for the misdiagnosis last year. At the time of your post there wasn't anything concrete that we could pin point to. In this instance, the OP was clear that he was doing an unused space erase on a FAT32 partition, which was handled by native code and does allocate memory.

I was examining it for a bit and found that Folder reparse points ARE followed but File reparse points are not. I also found that 6.2 has a different behaviour from 6.0 in that Folder reparse points are not followed there. So in this scenario I think the documentation just needs updating. I'm...

Thanks for reporting this: I'm looking at the code again now. I don't remember changing the behaviour, but I'll let you know when I got more information on my hands.

This has already been reported here and in other places. Please search before posting in future.

In the source code file you pointed out. I meant test - the test which will determine if Eraser thinks Shadow Copies are "enabled" (currently we're only equating existance of shadow copies with it being enabled). I don't think there's a way to determine if it's just enabled for the drive if...

Yup, confirmed bug in 6.0.10, after I changed the way it reports versions. Has been fixed and 6.0.11 will be fine.

You can see the test - System Restore can be on, but if there are no images, it's as good as off, isn't it?

Agreed about the fact on System Restore. Volume Shadow Copies on data drives tend to be hardier, especially if defragmentation processes do not move files around much.

And if you can't find the reference there, http://eraser.heidi.ie/forum/viewtopic.php?f=35&t=5309 is the direct link.

I think it is worthwhile to mention that disabling System Restore on any drive prevents Previous Versions to work, if you should use that feature. David, did we write this somewhere before?

That will probably be coincidental. Eraser does not tell Windows to get rid of shadow copies, but rather the system does that when disk space is low. Future versions of Windows may not do this.

Nope, shadow copies operate on the block level, in other words, the system will take a snapshot of the disk as it was, and only modify blocks that have changed since. Therefore, there will be no distinction between "normal" files and "system files"; everything will be imaged as one shadow copy...