Partial delete directory - stopped - now can't find remaining files/dir to finish delete ?

[scanreg]

I did a delete of a directory but I had to stop the delete process shortly after I started it, I figured I could come back to it and finish later

 

However, as soon as I clicked Stop (it was only 2% done), the directory (with contents) that I was deleting disappeared from the C: tree

 

How do I find the missing dir and contents to complete the delete?

 

Thanks

[Toppack]

If you are referring to a Windows 'Delete' operation then,

If you right-click on the 'Trash-bin' Icon (on desk-top), will it let you undelete?

(Is 'Undelete' option activated?)

If so, it was completely deleted.

 

If not a Windows File-manager 'Delete' command, what are you asking about?

 

Here's Info on the 'Run Line' Remove directory command:

If you need it.

Note- the syntax changed in XP

Link:

http://www.computerhope.com/rmdirhlp.htm

[scanreg]

I used the ASC Shredder via Right Click

 

I right-clicked the folder and choose Shredder, then in the Shredder options chose:

 

1. Wipe allocated disk space

2. Secure delete in accordance with DoD5220.22-M(ECE)

 

Should have mentioned these details in the opening comment, my apology

 

Does the above make a difference?

 

Thanks

[scanreg]

The Undelete option is enabled and Undelete is visible

 

I looked in the undelete window and did not find the folder/files that I mentioned

 

Question: under the Shredder/military delete system, it looked like the process was going to take some time (like a half hour or so cuz it was a lot of stuff) - however, if it still got deleted even though I stopped the process just 2% into it, how did it magically get deleted?

 

Thanks

[Toppack]

I've never tried to Stop the ASC Shredder utility, in the middle of a shred delete,

so have no experience with what would happen.

 

Sorry, maybe someone else on forum can tell you what to look for?

[solbjerg]

Hi scanreg

I am not sure - but perhaps the 2% is just enough to delete the items, but not enough to leave time for all the over-write operations the DOD deletion requires?

Cheers

solbjerg

 

The Undelete option is enabled and Undelete is visible

 

I looked in the undelete window and did not find the folder/files that I mentioned

 

Question: under the Shredder/military delete system, it looked like the process was going to take some time (like a half hour or so cuz it was a lot of stuff) - however, if it still got deleted even though I stopped the process just 2% into it, how did it magically get deleted?

 

Thanks

[Toppack]

Hi scanreg

I am not sure - but perhaps the 2% is just enough to delete the items, but not enough to leave time for all the over-write operations the DOD deletion requires?

Cheers

solbjerg

 

That seems logical, since most of the Time required is for Over-writes of the disk space.

[scanreg]

But doesn't it delete/overwrite one file at a time, then move to the next, etc?

 

I'm guessing that the reference to the directory might have been wiped out but the files might still exist?

[Toppack]

It's my understanding that if you are deleting a complete Folder (with sub-folders),

then the Shredder overwrites the complete disk-space used by those folders.

Not one file at a time.

 

I have read that if using the Gutmann algorithm, the complete deleted area will be overwritten 35 times before completion.

[scanreg]

I used the Mil method not gutman

 

Given that normal delete of this mondo directory would have taken maybe 20 minutes, I guess I don't understand how it could get wiped out in about 2-3 minutes

 

Especially when the shredder process window showed lots of files to go for the full deletion

[scanreg]

ASC 5.4.0, winxp

 

same thing just recently, cleaning recycle bin with very large files, ran shredder using mil, stopped well before completion, no files visible

[Scannan]

The delete function and the shredder are very different in their operation. In the delete function, the system simply changes the first bit from a 1 to a zero, but the path remains intact, and the file table retains the data, until such time as the allocated area is overwritten by new data. This may not happen for a long time depending on your available space etc... Thus undelete will be available to you. Additionally, when deleting a directory, the system checks to see if the files can be removed, ie,. they are not active and or being used by another application, in which case it will refuse to remove the directory.

However, the shredder, will immediately overwrite the allocated file area, and modify the file table, so halting the operation is unlikely to prevent the directory/files from being found again as the path no longer exists.

 

This is obviously a weakness / flaw in the shredder operation, and it is something that Iobit should maybe look at.

However, I imagine that it is assumed that if someone uses the shredder that they are sure that they definitely want the files/directory completely destroyed, and as such it is unnecessary to expect that they would want to find them again.

 

http://forums.iobit.com/images/icons/icon14.gif Good comment! Cheers solbjerg

[scanreg]

thanks for the detailed explanation, much appreciated

 

yes, shredding is for total destruction, but i guess i still wonder how much 'shredding' has occurred if the shredding operation has been halted early

 

for instance, could some of the data still be located by some super data finders, stuff that is used for instance for disaster disk recovery?

 

want to make sure we fully shred but sometimes need to cut the operation short cuz of time, etc, so would like to resume if at all possible

 

thanks

[Scannan]

Absolutely. I can understand your concern/fear. Unfortunately... only the Iobit programmers could answer that, as the only other way you would ever know is if one of the super hackers actually found the files.

It is most definitely a question which you should put directly to Iobit.

You can do it here....feedback@iobit.com

They are usually pretty quick with a reply.

I am sure they would appreciate the heads up on this possible weakness/uncertainty.

[scanreg]

thanks scannan, will do :)

 

....email sent