That's not the way hard drives and file systems work. At the lowest
addressable level, a hard drive is made up of sectors that may range in size
from 256 to several kilobytes in size, depending on the drive. Any time you
read or write from the drive, you read and write the entire sector.
For various, good reasons, file systems do not allocate one sector at a time
to a file, instead, an allocation block is used. The allocation block
consists of a number of sectors. When you create a file and fill it with
data, a number of allocation blocks are assigned to the file to hold the
data. When the file is deleted, allocation block is returned to the free
list (the list of blocks available for use for any file that needs them) but
the data in the the allocation block is NOT deleted. That is why you can
sometimes "unerase" a file - the allocation blocks that made up the file
have not yet been assigned to another file.
If a new file is created, one or more allocation blocks are assigned the new
file, and will contain whatever they had that the file they were previously
part of contained. Until new data overwrites the old (on a sector by sector
basis), the old data will be present. However, most applications do not read
past the "end of file," the last place the application placed data, so they
will never see the old data in the file. Some utility applications can read
past the end of file, and see the left over data.
On multiuser systems, this can be a security risk, when I erase a file,
somebody else may create one, and the data I had written is then
theoretically available to the other person. Multiuser operating systems
will usually implement a "high water mark" capability to prevent any
application looking beyond the end of file. This checking does reduce the
performance of the files system. They also typically include a "zero on
delete," where all data in a file is over written with zeros when a file is
deleted (which also impacts performance). On single user systems like a PC,
this is not an issue, so it is not implemented.
If you are really concerned about this issue, there are several utilities
that can zero out the unallocated blocks of your disk. You will need to run
them every time you quit an application to be sure that all data in
temporary files is deleted.
Eric Hildum
> From: "Erik J. Barzeski" <[EMAIL PROTECTED]>
> Reply-To: "Entourage:mac Talk" <[EMAIL PROTECTED]>
> Date: Fri, 17 Nov 2000 17:20:55 -0500
> To: "Entourage:mac Talk" <[EMAIL PROTECTED]>
> Subject: Re: Secret info in Sig file
>
> Hi,
>
> Two quick responses.
>
> Entourage:mac Talk <[EMAIL PROTECTED]> spoke thusly:
>> And the reason we don't zero it out is performance. It would be really slow
>> to have to zero out data whenever we created/grew files.
>>
>> Dan
>
> That data has never _been_ in a signature file. It shouldn't be _in_ the
> signature file. I don't know where it picked up the data. Sure, that data
> has existed on my hard drive, somewhere... But man... That's screwy. Cut the
> file off at the end of the signatures.
>
>> Looks like BBEDIT is letting you read past the end of file to see allocated
>> sectors that have not yet had signature data written into them.
>>
>> Eric Hildum
>
> That's not it... I've done enough tricks to make sure the file is _just_
> the file. I've checked the data fork, yada yada... What I pasted in is _in_
> the file.
>
>
> --
> Kindest regards,
> Erik J. Barzeski
>
> '"Hello World" - 12 errors, 31 warnings'
> ************************************************
> Email: [EMAIL PROTECTED]
> Web: http://www.barzeski.com/
> http://www.soundsetcentral.com/
> http://www.applescriptcentral.com/
> AIM: iacas ICQ: 8186546
> ************************************************
>
>
> --
> To unsubscribe: <mailto:[EMAIL PROTECTED]>
> To search the archives:
> <http://www.mail-archive.com/entourage-talk%40lists.boingo.com/>
>
--
To unsubscribe: <mailto:[EMAIL PROTECTED]>
To search the archives:
<http://www.mail-archive.com/entourage-talk%40lists.boingo.com/>
