Delete Files and Folders
ItsMe
I wanted to delete selected folders and files from a VB program. Right now I
am using FSO which takes sometime to delete. Usually these folders has
around 2 GB of data (temporary scanned images) which in turn may be spread
into thousands of small and large files.
Since, most of the times, we deal with customers very secured and private
documents (imported to digital format), it is necessary to make sure we are
using the best possible method to erase the files.
"I know that there are some virus which deletes our files beyond recovery
level". I need that kind of rock solid erasing method
Is it possible in VB or what is best way to achieve this?
Please help
Thattayan
Mike D Sutton
You'd need to open each file in binary mode and write null data to them up
until the length of the original file, then close and delete it. It's the
only way of knowing exactly which clusters on the disk the file is stored in
without using some very low level techniques such as peeking at the disk's
FAT (And even so, you'd still need to overwrite them so the first method
works just as well.)
Hope this helps,
Mike
- Microsoft Visual Basic MVP -
E-Mail: ED...@mvps.org
WWW: Http://www.mvps.org/EDais/
ItsMe
Is there any starting to learn to start peeking at this.
Further, is there any other way to delete a file quickly than using "Kill"
and FSO.
Regards
Thattayan
"Mike D Sutton" <Mike....@btclick.com> wrote in message
news:Ow8d510U...@TK2MSFTNGP10.phx.gbl...
André Joubert
you need to re-write multiple times. I have seen one which re-write the file
3 times with different bit patterns.
And of course the performance for deleting a file is drastically decreased.
André
"Mike D Sutton" <Mike....@btclick.com> wrote in message
news:Ow8d510U...@TK2MSFTNGP10.phx.gbl...
>
steve hotmail.com>
You can delete a file very quickly by writing 0's directly to the
allocation table but I'm not sure if you can do this in ntfs (or
windows for that matter). The data will still be on the disk but will
effectively be deleted from a user view point as there will no longer
be a pointer to it.
You should (as has been mentioned) overwrite your data with 0's
several times (norton wipeinfo used 3 passes) but you should probably
do this at a lower level than opening the file and writing 0's to it.
steve
André Joubert
faster.
André
"ItsMe" <m...@myweb.com> wrote in message
news:#Xk7#Q4UDH...@TK2MSFTNGP09.phx.gbl...
Mike D Sutton
> Is there any starting to learn to start peeking at this.
If you want the theory then I'd sure there's lots of sites that will explain
how disks and file allocation works, however you'd be less likely to find
the implementation itself but you could always have a hunt on Google. IMO I
wouldn't waste too much time on it, simply overwrite then kill the file.
Here's a function that would do this for you:
'***
Private Declare Function SetFileAttributes Lib "kernel32" _
Alias "SetFileAttributesA" (ByVal lpFileName As String, _
ByVal dwFileAttributes As Long) As Long
Private Declare Function MoveFile Lib "kernel32" Alias _
"MoveFileA" (ByVal lpExistingFileName As String, _
ByVal lpNewFileName As String) As Long
Private Declare Function DeleteFile Lib "kernel32" Alias _
"DeleteFileA" (ByVal lpFileName As String) As Long
Private Declare Sub RtlZeroMemory Lib "kernel32.dll" _
(ByRef Destination As Any, ByVal Length As Long)
Private Const FILE_ATTRIBUTE_NORMAL As Long = &H80
Private Function KillProperly(ByVal inFile As String) As Boolean
Dim TempName As String, GenTemp As Long
Dim FilePath As String
Dim FNum As Integer
Dim WriteBuffer() As Byte
Dim FileLeft As Long
' When VB creates an array, it should initialise the entire buffer to 0,
' however by enabling this, we'll use the ZeroMemory() API just to be
sure.
' i.e. Paranoia mode! ;)
#Const UseZeroMem = True
Const TempLen As Long = 10 ' Length of temp file name
Const BufLen As Long = 2 ^ 10 ' 1Kb write buffer
Const AscA As Byte = 64 ' ASCII code for char 'A'
Const AscZ As Byte = 90 ' ASCII code for char 'Z'
FilePath = Left$(inFile, InStrRev(inFile, "\"))
Do ' Generate a temporary, random filename (For this to
' work properly, the application should have called the
' Randomize() method to seed the random number generator)
ReDim WriteBuffer(TempLen - 1) As Byte
For GenTemp = 0 To TempLen - 1
WriteBuffer(GenTemp) = Int(Rnd() * (AscZ - AscA + 1)) + AscA
Next GenTemp
TempName = StrConv(WriteBuffer, vbUnicode)
Loop While FileExist(FilePath & TempName)
' Attempt to re-name the file, if this fails then it's most likely still
in use
FilePath = FilePath & TempName
If (SetFileAttributes(inFile, _
FILE_ATTRIBUTE_NORMAL) = 0) Then Exit Function
If (MoveFile(inFile, FilePath) = 0) Then Exit Function
' Get the size of this file
FileLeft = FileLen(FilePath)
' As long as we can write at least one full buffer, create it
If (FileLeft >= BufLen) Then
ReDim WriteBuffer(BufLen - 1) As Byte
#If (UseZeroMem) Then ' Clear buffer
Call RtlZeroMemory(WriteBuffer(0), BufLen)
#End If
End If
FNum = FreeFile() ' Open the file and lock everything else out
Open FilePath For Binary Access Write Lock Read Write As #FNum
Do While (FileLeft > 0) ' If this is only a partial segment,
re-scale buffer
If (FileLeft < BufLen) Then
ReDim WriteBuffer(FileLeft - 1) As Byte
#If (UseZeroMem) Then ' Clear buffer
Call RtlZeroMemory(WriteBuffer(0), FileLeft)
#End If
End If
Put #FNum, , WriteBuffer()
FileLeft = FileLeft - BufLen
Loop
Close #FNum
' Finally, kill the file itself (This just removes it
' from the FAT, but we've already toasted the data itself)
KillProperly = DeleteFile(FilePath) <> 0
End Function
Private Function FileExist(ByVal inFile As String) As Boolean
On Error Resume Next ' Does this file exist?
FileExist = CBool(FileLen(inFile) + 1)
End Function
'***
And yes, you could use VB's file handling methods (SetAttr(), Name and
Kill()) rather than the API (SetFileAttributes(), MoveFile() and
DeleteFile()) for this, however personally I prefer working with function
returns rather than VB's error handling.
> Further, is there any other way to delete a file quickly than using "Kill"
> and FSO.
You could look at the DeleteFile() of SHFileOperation API calls, there's
little difference in performance I would have thought.
André Joubert
If you decide to overwrite the file,
the buffer size you will use to do it has a great impact on
the performance. On a slow system, with slow hard disk
my tests revealed that anything less than 8K was absolutely
unacceptable. I have not made any test on newer systems,
my client was using very old equipement.
André
"Mike D Sutton" <Mike....@btclick.com> wrote in message
news:Ow8d510U...@TK2MSFTNGP10.phx.gbl...
>
Larry Serflaten
>
> You can delete a file very quickly by writing 0's directly to the
> allocation table but I'm not sure if you can do this in ntfs (or
> windows for that matter). The data will still be on the disk but will
> effectively be deleted from a user view point as there will no longer
> be a pointer to it.
>
> You should (as has been mentioned) overwrite your data with 0's
> several times (norton wipeinfo used 3 passes) but you should probably
> do this at a lower level than opening the file and writing 0's to it.
I had a short routine all ready to suggest that, but when I got done,
I could not be certain that the changes would actually have made it
to the disk. Between the OS file buffer and the disk buffers, I wasn't
sure if even closing the file between writes actually flushed the data
to the disk. I seem to remember mention of this in a similar question
some time ago. IIRC there was an API version that would flush the
buffers so I decided to hold back and see what others suggest!
;-)
LFS
Mike D Sutton
'***
Const AscA As Byte = 65 ' ASCII code for char 'A'
'***
Doesn't particularly matter though, since ' @ ' (Chr(64)) is actually valid
in a filename.
Tom Esh
<serf...@usinternet.com> wrote:
>...
>I had a short routine all ready to suggest that, but when I got done,
>I could not be certain that the changes would actually have made it
>to the disk. Between the OS file buffer and the disk buffers, I wasn't
>sure if even closing the file between writes actually flushed the data
Exactly.
Too many layers (OS, FS, firmware, hardware) and too many variations
within them before the physical write. No telling where it will end
up. Aside from the sledgehammer & blowtorch method, multiple
over-writes to the physical sectors is the only sure way to foil
recovery by examination of the physical media for data and residual
flux.
-Tom
MVP - Visual Basic
(please post replies to the newsgroup)
Rick Rothstein
> >I could not be certain that the changes would actually have made it
> >to the disk. Between the OS file buffer and the disk buffers, I wasn't
> >sure if even closing the file between writes actually flushed the data
> >to the disk....
>
> Exactly.
> Too many layers (OS, FS, firmware, hardware) and too many variations
> within them before the physical write. No telling where it will end
> up. Aside from the sledgehammer & blowtorch method, multiple
> over-writes to the physical sectors is the only sure way to foil
> recovery by examination of the physical media for data and residual
> flux.
Even the sledgehammer approach may not be enough. Although this is based on
readings of **several** years ago, I believe it to still be true (although
new technologies **may** have rendered it invalid). As I understand it, the
longer a file is on a hard drive, the harder it is to truly "erase". The
magnetism from magnetized "on" bits leech into the surrounding magnetic
material and magnetize them over time. A newly written bit will not "cover"
the entire magnetized area. When a hard drive is read, it does not read if a
bit is 100% magnetized or not, rather a confidence percentage is used. If a
bit is say 98% (not sure of the actual percentage, that's just a guess) of
the strength that a fully magnetized bit would be, then it is considered to
be "on". Really sensitive (read **government**) equipment can supposedly
write over every bit in on a hard disk with "zero" (not "on") and then read
this other "left-over" 2% and decide the bit "used to be" on. From that,
most if not all of a file could possibly be reconstructed.
Rick - MVP
Tom Esh
<rickNOS...@NOSPAMcomcast.net> wrote:
>Even the sledgehammer approach may not be enough. Although this is based on
>readings of **several** years ago, I believe it to still be true (although
>new technologies **may** have rendered it invalid). As I understand it, the
>longer a file is on a hard drive, the harder it is to truly "erase". The
>magnetism from magnetized "on" bits leech into the surrounding magnetic
>material and magnetize them over time. A newly written bit will not "cover"
Good point. I guess you'd call that residual residual flux. :-)
Probably explains why the gov't requires a thorough physical
destruction (whatever that involves) of old drives in some places. Not
that it matters much when they let some bozo waltz out the Los Alamos
front gate with an armload of data. <g>
Larry Serflaten
> Even the sledgehammer approach may not be enough. Although this is based on
> readings of **several** years ago, I believe it to still be true (although
> new technologies **may** have rendered it invalid). As I understand it, the
> longer a file is on a hard drive, the harder it is to truly "erase". The
> magnetism from magnetized "on" bits leech into the surrounding magnetic
> material and magnetize them over time. A newly written bit will not "cover"
> the entire magnetized area. When a hard drive is read, it does not read if a
> bit is 100% magnetized or not, rather a confidence percentage is used. If a
> bit is say 98% (not sure of the actual percentage, that's just a guess) of
> the strength that a fully magnetized bit would be, then it is considered to
> be "on". Really sensitive (read **government**) equipment can supposedly
> write over every bit in on a hard disk with "zero" (not "on") and then read
> this other "left-over" 2% and decide the bit "used to be" on. From that,
> most if not all of a file could possibly be reconstructed.
Since we have a major drive head producer in my area (within about 70 mi
of where I live) I thought I might find some corroborating information on
their site. I did not find information about any bleed-over, or residual, or
even percentage of confidence in the actual reading of the disk. I did learn
that the size of the 'bit' or bit spot, on the disk is related to how high off the
disk the write head is positioned and that we can probably expect drive
capacity to continue to increase.
For those interested in how the drive works....
(Suspension primer)
http://www.htch.com/primer.asp
(Areal density (Bits per square inch))
http://www.htch.com/datadensity.asp
LFS
Rick Rothstein
news:Or2FA%23GVDH...@tk2msftngp13.phx.gbl...
A quick search of the web using this search criteria
"hard drive" "residual magnetism"
produced a few links which discuss what they call "residual magnetism".
This is just one of them.
http://www.computerworld.co.nz/webhome.nsf/0/8F1D1CF40CD8C498CC256C5A006C76E6?opendocument
Rick - MVP
Rick Rothstein
> of where I live) I thought I might find some corroborating information on
> their site. I did not find information about any bleed-over, or residual,
or
> even percentage of confidence in the actual reading of the disk. I did
learn
> that the size of the 'bit' or bit spot, on the disk is related to how high
off the
> disk the write head is positioned and that we can probably expect drive
> capacity to continue to increase.
>
> For those interested in how the drive works....
> (Suspension primer)
> http://www.htch.com/primer.asp
> (Areal density (Bits per square inch))
> http://www.htch.com/datadensity.asp
This link seems to have much more detail on the storage and erasure problems
associated with hard drives.
http://www.usenix.org/publications/library/proceedings/sec96/full_papers/gutmann/
I would draw your attention to the 6th paragraph of Section 2 (Methods of
Recovery for Data stored on Magnetic Media) where it seems to talk about
what I called the "confidence level", although they don't describe it the
way I remembered it (from a reading of maybe 5 or more years ago). Also, the
6th paragraph of Section 5 (Further Problems with Magnetic Media) seems to
be a reference to the leeching problem I tried to describe from my
recollections. True, they don't say "leeching" in this article, but the
aging issue and extended "permanence" of the magnetic image were described
somewhat nearly as leeching in the old article I was referring to in my 1st
post.
Rick - MVP
steve hotmail.com>
I wonder if turning the bits on and off would confuse any low level
recovery software, rather than just writing 0s multiple times when
trying to securely erase files?
steve
Rick Rothstein
> recovery software, rather than just writing 0s multiple times when
> trying to securely erase files?
The recollections I have from past readings, and the articles I've recently
scanned (not read in detail) seem to indicate "not really". For old files,
the magnetic spots of information "spread out" into surrounding material
making the magnetic bit larger than what the write head can overwrite...
this excess magnetic signature can be read and a file reconstructed from it.
There also seems to be some kind of statistical analysis they can do using
some kind of differential signal strength or something (not fully clear on
the technicals here as you can probably tell by that high descriptive use of
jargon<g>) and read through the "overwritten" bits. The general consensus
seemed to be... if you don't want anyone (read "the government" here; the
equipment is expensive and the process time consuming so they're probably
the only ones who would do this, say, as part of an investigation) to read
you hard disk contents, open the drive up and totally destroy the platter's
magnetic coating.
Rick - MVP