> 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.

Please read again the reasonably well explained introduction to Hard Drive
Realities 101.

>> 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.
> 
> 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.

See the previous request.


Sadly, I can't think of any truly good real world analogies.

But I'm going to go for this one.  Imagine that you have a VCR, a 2 hour
videotape (1), and a truly annoying roommate.

Unbeknownst to your roommate, this particular videotape has been used, by
you, dozens of times to record you and your significant other in many
intimate acts.

Your roommate's friend asks him or her to record a show.  It's a a half hour
long.  Your roommate records the show and hands the friend the videotape
(2).


Anyway, the signature portion of the signature file is the first half hour
of the videotape.

The "random" cruft afterwards is the remaining 90 minutes.

Of course, this doesn't help "solve" your problem.


#####

If this is truly a problem for you, I suggest you start with these:
   <http://polsoft.8m.com/scorch.html>
   <http://users.iol.it/yellowsoft/theeraser.html>
There are commercial options available as well.

In reality, in order to truly work, you need large scale changes to the
Macintosh filesystem.

mikel

(1) Why do I want to say a point-mass bulldozer of infinite mass with a zero
coefficient of friction?

(2) You of course become aware of this when you see the URL on a staff
mailing list at work...but that's another story.

PS: *ALTHOUGH*...what is "complicating" the issue here is that MS's file is
bouncing the EOF out to 12560 bytes at creation time.  And they're then
using that 12560 bytes essentially as a database of short.  Internally,
Entourgae "knows" which part of the file is cruft and which is data.  But
there is always some cruft data that is most definitely part of the file.
So, would you believe that both sides are partially right?


-- 
To unsubscribe:               <mailto:[EMAIL PROTECTED]>
To search the archives: 
          <http://www.mail-archive.com/entourage-talk%40lists.boingo.com/>

Reply via email to