From: Ajo Wissink on
On Tue, 09 Mar 2010 19:37:05 +0000, me(a)privacy.net wrote:

>I have some emails in my Trash folder, in Eudora 7.1.0.9. I choose
>menu option Special/Empty Trash, Special/Compact Mailboxes. When I
>look again at the Special menu, the Empty Trash menu item is grayed
>out.
>
>Does this always mean there are no further items to be emptied from
>the trash? In other words, if it is grayed out, does that always mean
>the Trash mailbox is empty?
>
>Silly question perhaps, because the answer is plainly Yes, but I would
>like some reassurance on this point.

The answer is plainly YES ;)
From: John H Meyers on
On 3/9/2010 6:13 PM, Steve Urbach wrote:

> Until you compact the trash mailbox,
> there may be some remnant info hidden in the file.

If you display Trash and then empty Trash,
it will automatically be compacted upon closing it,
due to then having 100% "wasted space."

However, no trashcan is ever safe:
http://www.straightdope.com/columns/read/2897/who-owns-my-garbage

--
From: John H Meyers on
On 3/13/2010 5:39 AM, me(a)privacy.net wrote:

[I don't know what, because either my reader or my server shows a blank post,
perhaps because the OP has already sent a "black hat" to delete it;
sorry that this will therefore not be "threaded" properly]

The ever awake Google, however,
which some say is the "Big Brother" predicted by Orwell,
has already recorded the outburst as:

> If the Trash mailbox is empty, does it automatically get compacted
> on exit from Eudora, or do you have to set a checkbox in Options?

I'm not aware that anything gets compacted on exit from Eudora,
but you can answer the question for yourself,
as any self-respecting paranoid or O-C should,
by simply experimenting, checking the file size afterward --
an empty mailbox (e.g. trash.mbx)
that has no deleted messages within it will have zero length.

You can also answer it by re-opening Eudora
(without downloading new messages, i.e. "check every 0 minutes")
and seeing whether the "wasted space" shows up as zero at that time.

> If you do Special/Compact Mailboxes, does it always
> compact the mailboxes so there is no excess left?

That is indeed what the function is supposed to do,
according to the manual, but in case the manual is wrong,
or the program contains a bug, or is crippled by the NSA,
you can, as above, check all mailbox indicators upon re-opening
(unless the NSA has also crippled those from showing the truth).

This has by no means covered all bases, since we have not asked
how messages got into the Trash in the first place.

Before being _copied_ into the Trash mailbox, a message was
in some other mailbox, and its "deletion" from that other mailbox
usually leaves the original in place in that original mailbox,
only its original TOC entry having actually been "deleted."

If that other mailbox was either "In" or "Out," then even if
you "Compact" "In" or "Out" afterward, Eudora keeps each
pre-compacted mailbox file by appending ".001" to its file name,
after "aging" any older ".001" file by renaming to ".002" and so on.

These "backups" (.001, .002, or possibly even more)
are never compacted by Eudora at all, because the entire idea
is to protect you from corruption caused by compacting,
by keeping the originals anyway, in case you need to recover them.

Also, the process of compacting simply creates a brand new file,
"deleting" the old file either immediately afterward
or much later in the case of "In" or "Out," as noted above.

"Deleting" a file, in turn, simply marks some disk directory entry
as not being in use any more, so that the file will not be listed
any more, but the rest of that directory entry still exists,
as does all of the disk area where the file content was written.

This is, after all, how various "file recovery" programs
manage to bring old files back from the dead -- some software
even stops windows from actually deleting anything, instead
just transferring "deleted" files to some "protected trash can" area
(the superior Netware OS always keeps files recoverable; so does
Vax VMS retain some number of prior "versions" of every file).

You aren't finally rid of "deleted" file data until every disk block
of the original file has been overwritten, not just by new files, but
by a "wipe all free blocks on disk" program, and then by a more detailed
"wipe all slack space on disk" program, which writes into the tail ends
of files which even currently exist, but whose allocated space
(in multiples of some basic block size) contains a bit left over,
between the last byte of the file and the actual end of its last block,
which can contain data from whatever file(s) previously rented that block.

While re-writing disk blocks, the nature of magnetic material
is such that just like washing your hands, it may take
several re-scrubbings to really get out the last remnants of dirt,
detectable under a microscope even long after the normal disk read head
pays more attention to the last-written swipe, because tiny misalignments
between swipes still leave little traces behind, at the sides.

The vast Microsoft-NSA-hardware conspiracy still has many other
potential tricks up its sleeve, such as "alternate data streams"
in Windows files (vaguely like "resource forks" in Mac OS),
automatically relocated hardware sectors on disks
(particularly on "flash" memory devices, where all sectors
are virtual, and get relocated continually),
and oh, don't forget "virtual memory swap files,"
where data that ever was in memory may at some moments
have been sidelined to a disk, to let some other program
splash around in the same RAM for a while.

When push comes to shove, the only sure way to send old data to hell
is to throw the entire computer into the Sun, if not into a black hole,
if you can afford the price of a Russian space tourist flight to get there.

And if some spyware had already sent your files over the internet
to a secret under-glacier facility where every byte is being stored,
to keep current government in power through the next Ice Age,
then it all was for naught anyway.

Sleep well, and pleasant dreams.

--