Jihad needs scientists
in [Design]
|
From: jmfbahciv on 3 Mar 2007 07:27 In article <es9djf$q95$3(a)blue.rahul.net>, kensmith(a)green.rahul.net (Ken Smith) wrote: >In article <es928h$8ss_001(a)s1006.apx1.sbo.ma.dialup.rcn.com>, > <jmfbahciv(a)aol.com> wrote: >>In article <es829g$2hl$2(a)blue.rahul.net>, >> kensmith(a)green.rahul.net (Ken Smith) wrote: >[...] >>>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. >>I'm assuming that you do want an image of the disk and not drive. > >Preseving the bad spots is a feature not a problem. It is a record of >exactly how things were warts and all that you want to keep. > >>>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. > >Please explain exactly how you thing the last access is important. [This is the piece I inadventently deleted] > What >do you do with this information? I, the BACKUP programmer, will save all files during an incremental that has an access date after the date-time argument of the /SINCE switch. > In this context, the only use of that >information will be a mistake. Are you interested enough to read some code which implements this stuff correctly? /BAH
From: jmfbahciv on 3 Mar 2007 07:30 In article <MPG.2052091685c10ec298a03a(a)news.individual.net>, krw <krw(a)att.bizzzz> wrote: >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. I'm assuming that this housekeeping moved into the smart controllers. > 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. So what does a bit-to-bit copy of the physical mean? Bit-to-bit implies all bits, including the ones covered by the error handler... doesn't it? Oh...were they using the term incorrectly again? /BAH
From: jmfbahciv on 3 Mar 2007 07:32 In article <n6pgu2t4icsmaqnfvjq993e0oioq1mgais(a)4ax.com>, MassiveProng <MassiveProng(a)thebarattheendoftheuniverse.org> wrote: >On Fri, 2 Mar 2007 10:13:24 -0500, krw <krw(a)att.bizzzz> Gave us: > >> >>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. >> > Exactly. And it is done ON the hard drive electronics 100% >independent of the OS or machine the drive is powered by. > > We called it "maps out bad sectors". They get "mapped out" of the >available areas on a drive, and your "cached" area gets a piece >"mapped in". The drive "map" tells the drive hardware where all the >available write areas on the drive are located. This is nothing new. <snip> /BAH
From: jmfbahciv on 3 Mar 2007 07:33 In article <0cmgu2dlhs2216kspmk6tqf2ehboc3f171(a)4ax.com>, MassiveProng <MassiveProng(a)thebarattheendoftheuniverse.org> wrote: >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. You have become confused. We're talking about using last access as part of the backup strategy. /BAH
From: jmfbahciv on 3 Mar 2007 07:35
In article <MPG.20520a9f9e61c03b98a03c(a)news.individual.net>, krw <krw(a)att.bizzzz> wrote: >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. > What prevents multiple scans? /BAH |