Eric Hildum
Fri, 17 Nov 2000 17:16:25 -0800
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/>