Jihad needs scientists
in [Design]
|
From: jmfbahciv on 2 Mar 2007 07:25 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. /BAH
From: jmfbahciv on 2 Mar 2007 07:33 In article <es6rgr$kgg$6(a)blue.rahul.net>, kensmith(a)green.rahul.net (Ken Smith) wrote: >In article <es6h92$8qk_001(a)s985.apx1.sbo.ma.dialup.rcn.com>, > <jmfbahciv(a)aol.com> wrote: >>In article <es5i08$ujr$3(a)blue.rahul.net>, >> kensmith(a)green.rahul.net (Ken Smith) wrote: >[....] >>>The "in a writable mode" makes this a very different statement. >> >>Each time you copy, the file has been in a writable mode. > >The output side must be writable but not the input side. This means that >there may be an error in the copy you make but you don't change the source >file. Which file will be restored? Not the original. Our distribution tapes had copies of the originals. > When the copy process does the verify, the error will almost >certainly be detected. You also keep assuming that only hardware errors happen and that all hardware errors are detected and that those, which are detected, will be reported. Honey, you are not paranoid enough. > >[.....] >>>That is a case where the file has been modified not merely opened for >>>reading. >> >>Has the date changed? Then some part of the overhead of the >>file has changed. If you are saving this file to a backup tape, >>you are writing that file to another device. If you have >>an OS that keeps track of written blocks, then the list of >>those blocks can be changed, especially if a bad spot forms >>on the device. > >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. Verifying requires a second "save" to occur. Even the old days a full system save couldn't be saved and verified in one night. Nowadays you have disks that have capacities in the giga-thingies. > > >>Those are only a few of the things that can go wrong. There >>is always the midnight editor. On a network? There are lots >>of opportunities to get a file modified without your knowledge. > >None of this changes the fact that you mixed up back up, restore and >repair. The whole reason you do a back up is because files can be changed >when they shouldn't. This is not a question we have been arguing. I have, almost consistently, been talking about files disappearing. Plus all the things that can go wrong along the way. > > >>>>"Reliable" systems are defined by a threshold in the number >>>>of errors/some_number of operations. But you knew that, no? >>> >>>Yes, I knew that but it appears that BAH doesn't understand about the >>>difference between making a back up, doing a restore and repairing damage. >> >>I do. I simply posed the situation where the problem that caused the >>mess is also on the backup. Doing a restore will restore the >>mess maker. > >As I pointed out, this is exactly what a restore would do. It puts the >files back as they were on some date in the past. If the files are not >right on that date, those incorrect files are exactly what you want a >backup to have on it. You have mixed up the question with one of repair. >That is a different topic. If you are restoring the virus that is causing you to rebuild your system, you will be rebuiling your computer system over and over and all over again. You will never, ever, get out of restore mode until you stop restoring the virus (a.k.a. the mess maker). /BAH >
From: jmfbahciv on 2 Mar 2007 08:22 In article <qbjfu2564n2re0pk89qnuc20r1ggdjji45(a)4ax.com>, MassiveProng <MassiveProng(a)thebarattheendoftheuniverse.org> wrote: >On Thu, 01 Mar 07 12:34:42 GMT, jmfbahciv(a)aol.com Gave us: > >>Each time you copy, the file has been in a writable mode. > > > Wrong. The host file has a snapshot taken of it. If large, it will >get read sequentially as the copy takes place. The TARGET file must >be "open" to be "created". > > The original file is NOT EVER in "open" mode, and was not ever in a >"writable mode" during a simple copy function. If a backup has to be restored, it is the original file which has disappeared. Now, which file are you restoring? It's the one that was written. I never believed that this subject matter was so difficult to understand. None of our customers had problems. Not only did I work with bit gods, we must have had customer gods. > > That is why any file which IS "open" and in write mode cannot be >accessed by any other user until said write has been performed, and >the file released. > > Database "tables" are the exception, 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. >where the database engine >"opens" the table file, and allows what could be called a "co-edit" >session on the table. At that point, the lockout is at the "record" >level, and the same table line cannot be "co-edited", even though the >table itself can. That is all managed within the database engine, >however, not at the file level. This is why database hard drives can >become very fragmented. Tables get updated a couple kB or less at a >time. That makes for a very spotty file system (well, it used to) >NTFS changed all that, and Linux never suffered the problem. > > Normal OS file rules prohibit file "co-edit" sessions. Nope. It can be done but you really have to know what you're doing. We implemented a system calls that would help different programs "share" files. /BAH
From: Phil Carmody on 2 Mar 2007 08:32 jmfbahciv(a)aol.com writes: > Each time you copy, the file has been in a writable mode. Explain the above in the context or WORM media. This will be funny... Phil -- "Home taping is killing big business profits. We left this side blank so you can help." -- Dead Kennedys, written upon the B-side of tapes of /In God We Trust, Inc./.
From: Phil Carmody on 2 Mar 2007 08:42
jmfbahciv(a)aol.com writes: > You are in error. Last access is an important datum. Not universally. I'd be tempted to say very very rarely, except in a few forensic situations. Are you familiar with the concept of reading filesystems read-only? Are you suggesting that it's important that no-one ever do so, lest they lose that important datum? Phil -- "Home taping is killing big business profits. We left this side blank so you can help." -- Dead Kennedys, written upon the B-side of tapes of /In God We Trust, Inc./. |