From: MassiveProng on 2 Mar 2007 12:07 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 2 Mar 2007 12:24 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 2 Mar 2007 12:42 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 2 Mar 2007 12:43 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 2 Mar 2007 12:47
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. |