Jihad needs scientists
in [Design]
|
From: Ken Smith on 2 Mar 2007 09:52 In article <87tzx3ahj9.fsf(a)nonospaz.fatphil.org>, Phil Carmody <thefatphil_demunged(a)yahoo.co.uk> wrote: >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? When a restore is done, the backup volume is mounted as read only. Back in the days when tapes had a "wrong ring", the write ring was always removed from the tape as soon as it was dismounted. -- -- kensmith(a)rahul.net forging knowledge
From: Ken Smith on 2 Mar 2007 10:06 In article <es95ji$8qk_001(a)s1006.apx1.sbo.ma.dialup.rcn.com>, <jmfbahciv(a)aol.com> wrote: >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. Restoring is the process of putting the machine back to the way it was on a given day. This means that the version that was on the disk at the time of the backup is the one that must be put back. To do anything else takes us out of the area of doing a restore. >> When the copy process does the verify, the error will almost >>certainly be detected. > >You also keep assuming that only hardware errors happen No, I don't. I have suggested many cases where the software is at fault. > and that >all hardware errors are detected Again, no I don't. You need to read more carefully. > and that those, which are >detected, will be reported. ....and a 3rd time. > >Honey, you are not paranoid enough. I have suggested the reasonable way to deal with the problems of doing a back up. You are so determined to prove me wrong that you haven't even read and thought about what I wrote. You just bark some new claim at the thread and assume that it will convince people. [....] >>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. The disks and computer have gotten faster more than they have gotten bigger. Today it takes less time to image my 250G disk than it did the 10M Winchester that was the first one I imaged. [.....] >>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. Yes so we have always agreed that the reason you do a backup is because the files can change at times when they shouldn't. Hopefully we can now put this question away. [.....] >>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). No, I am not completely stupid, as you seem to want to imply. The restore puts things back to the way they were. This means that if the system was broken on a given day, that exact situation is recorded on the back up. An earlier back up would have the system as it was on some day before things went wrong. This is exactly what you want back ups to act like. They are complete pictures of the system on a given day. The restore process lets you put things back as they were. The repair process is how you make the system correct. -- -- kensmith(a)rahul.net forging knowledge
From: krw on 2 Mar 2007 10:13 In article <es928h$8ss_001(a)s1006.apx1.sbo.ma.dialup.rcn.com>, jmfbahciv(a)aol.com says... > In article <es829g$2hl$2(a)blue.rahul.net>, > kensmith(a)green.rahul.net (Ken Smith) wrote: > >In article <87fy8paqu8.fsf(a)nonospaz.fatphil.org>, > >Phil Carmody <thefatphil_demunged(a)yahoo.co.uk> wrote: > >>kensmith(a)green.rahul.net (Ken Smith) writes: > >>> >ls -lu > >>> > >>> I assume you had a point. > >> > >>I think his point is that access time is part of the metadata > >>that accompanies the file. > > > >It is not stored into the data part of the file. The file's sectors are > >not rewritten so there is no change to that part. I believe that it is > >the time you close the file and not the time you opened it that actually > >ends up stored BTW. None of this matters to the backup method I > >suggested. > > > > > > > >>So we have 3 cases: > >>- If it doesn't change the last-accessed time, then the "last- > >>accessed time" is in fact a falsity; > >>- If it changes the last-accessed time and stores the new access, > >>then the restored file will not be what it was a backup of; > >>- If it changes the last-accessed time but doesn't store the new > >>time, then the file in the backup is not identical to the > >>filesystem that it is a backup of. > >>All three of these are unsatisfactory. Therefore I contend that > >>this field is indeed not a useful field when it comes to considering > >>the behaviour of backups. > > > >No, this is all silly. The backup I have been refering to is not cover in > >the cases in your list. What I suggested was a complete image of the > >drive. > > That has the problem of also preserving the bad spots of the disk. Modern disks don't show their "bad spots" to the system. They're replaced from a cache of hidden sectors as they fail. This doesn't mean it isn't possible to lose data when one fails though. > I'm assuming that you do want an image of the disk and not drive. > > >This would store the times as they were at the time archive was > >made and not change anything about any of them > > > >The only times that matter for backup are the time of creation and the > >last modification. It doesn't matter when the last access happened. > > You are in error. Last access is an important datum. -- Keith
From: Ken Smith on 2 Mar 2007 10:14 In article <es98ds$8qk_001(a)s1006.apx1.sbo.ma.dialup.rcn.com>, <jmfbahciv(a)aol.com> wrote: [....] The other stuff I've spoken to elsewhere. >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. This is not always true. In a multidisk mirroring system, you can do a commit and unmount one drive. It will be an image of what was there at the time the commit happened. Disks are fast enough that this option can be used for most applications. The delay caused by the OS's commit operation is not very long. [....] >> 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. Note his word "normal" in the above. You can have multiple streams of data going to a file even on a Windows machine. All that is needed is to have one task that does the actual write operations. This is usually combined with "event based" recording where the transactions are recorded with time stamps so that the correct order is insured. -- -- kensmith(a)rahul.net forging knowledge
From: krw on 2 Mar 2007 10:19
In article <es92g1$8ss_002(a)s1006.apx1.sbo.ma.dialup.rcn.com>, jmfbahciv(a)aol.com says... > In article <MPG.2050cf07addd0e6298a031(a)news.individual.net>, > krw <krw(a)att.bizzzz> wrote: > >In article <0sccu2tencv0vqes1nru8uec7if9e8f4cm(a)4ax.com>, > >MassiveProng(a)thebarattheendoftheuniverse.org says... > >> On Wed, 28 Feb 2007 15:02:48 -0500, krw <krw(a)att.bizzzz> Gave us: > >> > >> >In article <97v6u2hhdaf437oki5ujqt4q3gkjghn3dv(a)4ax.com>, > >> >MassiveProng(a)thebarattheendoftheuniverse.org says... > >> >> On Mon, 26 Feb 07 12:36:17 GMT, jmfbahciv(a)aol.com Gave us: > >> >> > >> >> >> > >> >> >The wrinkle to the new process is that the checks have stopped > >> >> >traveling. > >> >> > >> >> > >> >> Bullshit. My landlord gets a check, and his bank submits it to my > >> >> bank who has it ON FILE RIGHT NOW, I get an image of the check in my > >> >> mailed monthly statement, and can look up a full size image of all my > >> >> checks online. > >> > > >> >Dumber-than-a-dim-bulb, you're wrong. > >> > >> No. You are. I can even request the return of the check. > > > >Not if it's been cleared via "check 21". The check paper check is > >turned into bits and the hard copy destroyed. > > This is the bug in the process, IMO. The process depends on the human, > who is scanning the physical paper, to destroy it. It doesn't matter if the physical check is destroyed or not. The routing and account numbers are all that matters. The paper check is only a carrier for those. -- Keith |