on 11/17/00 6:26 PM, Eric Hildum at [EMAIL PROTECTED] wrote:
> 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.
In the "Signatures" file case, it is not just that the unused portion of the
allocation block has random data. The random data is part of the file (ie.
it is before the EOF), which is why you see it with BBEdit. BBEdit is NOT,
as someone said, reading in the whole sector/block, just requesting the data
up to EOF. The random data would be included if you copied the file to
another disk, unlike data past EOF in the unused portion of the last
allocation block.
Presumably Outlook/Entourage requests that files be "grown" in chunks, and
manages the space as required. The File Manager "SetEOF" and "Allocate"
calls don't zero out the allocated space, and OE doesn't, presumably for
performance reasons. If this is an issue for people, perhaps Microsoft
could zero out unused sections of these files as part of the "Rebuild"
process?
--
David Oberst/NWT Bureau of Statistics/Yellowknife, NWT, Canada
[EMAIL PROTECTED] [Explore Canada's Arctic]
--
To unsubscribe: <mailto:[EMAIL PROTECTED]>
To search the archives:
<http://www.mail-archive.com/entourage-talk%40lists.boingo.com/>
