From: MassiveProng on
On Fri, 02 Mar 07 11:36:49 GMT, jmfbahciv(a)aol.com Gave us:

>You are in error. Last access is an important datum.


You are in error. Updating "last access" data in a file's header is
NOT a dangerous or volatile access of the file, and does NOT pose any
danger to it.
From: MassiveProng on
On Fri, 02 Mar 07 12:25:31 GMT, jmfbahciv(a)aol.com Gave us:

>In article <9abb5$45e6dbbb$4fe70c3$30531(a)DIALUPUSA.NET>,
> "nonsense(a)unsettled.com" <nonsense(a)unsettled.com> wrote:
>>jmfbahciv(a)aol.com wrote:
>>> In article <epccu25dvaomn9ak8i5fmq0lks6prbbtuh(a)4ax.com>,
>>> MassiveProng <MassiveProng(a)thebarattheendoftheuniverse.org> wrote:
>>>
>>> Aren't you out of vital bodily fluids yet?
>>
>>This is what happens when you free the serfs.
>
>Even serfs have been toilet trained and know the best
>use of those other fluids.

Your senility is showing again, witch. Don't you have a grave site
or an urn of ashes to talk to? Do you really feel so compelled to try
to talk to us? If you're such a bit god, invent something!
From: MassiveProng on
On Fri, 02 Mar 07 12:33:54 GMT, jmfbahciv(a)aol.com Gave us:

>>This is only a problem with this copy of the file and not with the one we
>>were backing up. You have also ignored the verify step which is always
>>done.
>
>No, it is not.

Bullshit. It used to be a flag the user could turn off. Now ALL
files get a checksum verification at ALL times. With large files the
data is kept sequentially, as in a "running checksum" figure is kept
as the file write occurs, and the final value has to match the
checksum for the file.

This is even how file download managers work to allow resuming of a
transfer to be properly addenumed <sp> to the file. That way I can
download entire DVD images of Knoppix at 2 MB pre second. Stop, go
get lunch, come back and turn my computer back on and resume the file
WRITE where it left off! HAHAHAHAhahaha. 4.6GB reception success!

> Verifying requires a second "save" to occur.

Wrong. You are living in the dark ages. After a block of data is
written, it gets read, and the checksum for that block is kept, and
the next block gets written, then read, then the checksum gets
updated. The checksum is stored in RAM, and at the end of the file
write, the checksum must match the checksum provided in the file
header. No dual save is required. You are decades behind the rest of
the world.

>Even the old days a full system save couldn't be saved and verified
>in one night.

Nowadays, a power supply for a government computer has a single rail
that is meant fore critical saves... "core dumps" to take place at the
moment power is taken from the system. This "core dump" takes place
within a 150ms window!

> Nowadays you have disks that have capacities
>in the giga-thingies.

Yes, and there was a time that a power outage during a write cycle
not only meant that that particular file was hosed, but the retracting
head arm could "spray" write energy all over your platter as it pulls
back out screwing the whole drive up. This is no longer a problem.

So many things you have claimed as problematic are not such any
more.

That is your main problem.
From: Tony Lance on
Big Bertha Thing Extract
Cosmic Ray Series
Possible Real World System Constructs
http://web.onetel.com/~tonylance/readme.html
6K Web Page
Astrophysics net ring Access site
Newsgroup Reviews including sci.astro.amateur

Extract from Readme file to explain the Outlandish Particle Periodic Table.

From Pastures Software Package Documentation.
(Particle Structure Results Program in Fortran 77.)
Sub-atomic Mesons, Baryons and Leptons Classification System.
(C) Copyright Tony Lance 1997
Distribute complete and free of charge to comply.


Big Bertha Thing Deaf

One day God woke up, deaf-as-a-post. He could not hear anyone
speaking. Nothing, dinada, zilch, not even one line e-mail.
Fortunately it only lasted 6 days and He managed to keep himself busy.

A PPT takes 6 hours people time, 18 hours computer time. It just
seems longer.

Tony Lance
judemarie(a)bigberthathing.co.uk


From: Tony Lance <judemarie(a)bigberthathing.co.uk>
Newsgroups: swnet.sci.astro,sci.chem
Subject: Re: Big Bertha Thing warlord
Date: Tue, 20 Feb 2007 13:13:15 +0000


Sunday, November 16, 1997 04:39:18 PM
Message
From: Mansour Abou Jaoudy
Subject: Re: Fwd: Big Bertha Thing 5
To: Tony Lance
Hiya Tony

There are some questions about what do you mean by the postings of "big bertha thing"
thread.
people are confused (me too). it will be nice if you could explain,
before they put you in fire ;-))

take care
Mansour
From: MassiveProng on
On Fri, 02 Mar 07 13:22:04 GMT, jmfbahciv(a)aol.com Gave us:

>The case that I brought up was database; with databases, the data
>is always a moving target that can never be snap-shot with accuracy.


You're an idiot. That would only be true for a LIVE database. If
you are doing file maintenance, the database would be a static file,
and that server would be offline.

ANY file can be snapshot accurately. A database table that is
fragmented over a volume gets written in backup as a single block of
data, and nothing is lost. Some lost space is gained in fact.
Database engines allow table optimization which essentially defrags a
single file.