jaclaz

Yep . All in all, I would say that most probably chances are a bit lower than what initially estimated, but still in the same order of magnitude. Just for the record, my previous post took "your" 1,000,000,000 and divided it, for several reasons, by several factors: 3 (maybe current production) 3 (maybe number of drives in the "family") 1.1 (rounding by defect)=>at this stage the number of drives in the possibly "affected" family is 100,000,000, i.e. 1/10 of "your" 1,000,000,000 10 ("safety factor")=>at this stage the number of drives in the possibly "affected" family is 10,000,000, i.e. 1/100 of "your" 1,000,000,000 500=1/0.002 (to take into account Seagate statement) (3*3*1.1*500*10)=49,500 i.e. 1,000,000,000/49,500=20,202 => 20,000 In other words, the hypothesys is that throughout 2008 Seagate manufactured between 10,000,000 and 100,000,000 drives of the "family". Then, the lower number is taken and multiplied by the smallest possible incidence of "affected drives" (per Seagate statement) 0.002, i.e. that 1/500 of the drives in the family may be affected. Since "some percentage" can mean ANY number <1, the found 20,000 can easily come out by a lesser number of drives "in the family" manufactured multiplied by a higher percentage: 10,000,000*0.002=20,000 (1/500) 5,000,000*0.004=20,000 (1/250) 2,500,000*0.008=20,000 (1/125) 1,000,000*0.02=20,000 (1/50) while still within the same definition of "some percentage", and at the lower end of it...... Without official data, and as clearly stated, the above numbers are just speculative, and, while they might be inaccurate, the order of magnitude seems relevant enough to rule out that the 100÷150 reports here on MSFN, represent NOT a significant fraction (1/7 or 1/8) of all affected drives. jaclaz

Thanks for the heads up. Of course this will draw a neat line between Vista/XP and previous OS's. Let's hope we'll have soon a 9x/Me and 2K (besides Linux, for which an experimental - read only - driver has been made and things seem to be "in the works" ). jaclaz

Still, not entirely my point, it's a bit hard to explain myself. the 1/3, in the hypothetical system depicted, makes things a bit different depending on values with which the initial counter is set in factory. First 3 "critical values" are: 320 =(320*0+256) 576 =(320*1+256) 832 =(320*2+256) Since 320 cannot be divided by 3, IF the counter is initially set to 0, AND all logs are made in three entries, you have 0% probabilities to hit 320, as 106*3=318 (n=106) and 107*3=321 (n=107) next occurrence is 256 steps away, but since 320+256=576 can be divided by 3, you have 100% probabilities (read certainty) to hit 576 (with n=192), and so on. If the counter is intially set to 1, you have 0% probabilities to hit 320, as well as 0% probabilities to hit 576, but you will hit 832 with (with n=277) If the counter is intially set to 2, you have 100% probabilities to hit 320, (with n=106) If the counter is initially set to 3, same as if it were set to 0, only first hit will come at corresponding n-1: 192-1=191 ...and so on. Of course, just as in the case of a single event log per power cycle (where if you started with value 319 you were dead on first shot), if you start with 317 you are dead, but if you start with 319 you have 171 chances before hitting next "critical value". Best value to start with is 1 with which you have 277 cycles, but starting with 4, 7, 10 .... will only lessen your cycle life by 1 , 2, 3, etc. If you are unlucky and start with 2, you have only 106 cycles...... Roughly the difference between 3 and 9 months of "life". If the logs are written sometimes in triplets, sometimes in couples, sometimes in single "lines", I don't think there is a way to calculate probabilities, but however the probabilities should be lower than what calculated for all single "lines". jaclaz

If one could go this way , "other possibilities" include (with the premise that the OP may keep the PC underground, but knows what the BIOS is) that a little mouse could have eaten the IDE or SATA cable. B) More seriously, I have seen often SATA cables get disconnected even if the case had no or very little shocks/movements...double checking cables would be a good idea anyway. jaclaz

If the drive is not detected by BIOS: the poor MBR appears as innocent, as well as "other media" and probably also "sata mode".... jaclaz

Could you please state exact version of BOOTMGR.EXE's? "latest WAIK" and "a previous WAIK" are a bit labile as references... jaclaz

@Gibby @Oliver.HH What I was trying to say here: http://www.msfn.org/board/index.php?showto...092&st=1048 was that if certain events are logged "in pairs" or in "triplets", the actual probabilities would lessen a bit. Take as an example the "normal" XP Event Log, you usually get when booting NT based systems a : 6009 - Microsoft ® Windows ® 5.01. 2600 Service Pack 2 Multiprocessor Free. 6005 - Event log service was started And a: 6006 - Event log service was stopped when switching off. In "normal" power cycle of a (highly ) hypothetical install where no errors, no warnings, nor other notifications are logged, the entries would be always in triplets. To get to 320 in such a system, the "initial" address x would have to be x+3*n=320 as a function of n power cycles, i.e. only values satisfying x=320-3*n, from the bottom: thus reducing the probabilities to 1/3 of what calculated for the "single event" addition. About this: Here is a simple graph for first 12 months (assumed as being 30 days each, using working days of course will flatten the curve): I see it more like gambling on a coin throw: Everytime you switch the thing on you throw a coin, on average for the first six months you will win, besides being not at all what one is supposed to do with data, gambling beyond six months, where percentage gets to 50.6% is betting money on an "unfair" game. jaclaz

being sure that the read-only CD-like device (and the source files in it) cannot be tampered with? not needing any modification to a working CD/DVD? jaclaz

I am not sure I get fully your question. If you use migrate.inf, the stick will be U:\. So you should be able to SET CDDRIVE=U:\ And live happily. Of course without knowing which paths you use in cmdlines.txt and in your batch files it's impossible to say whether they will work or not. If the batches or whatever point to: %CDDRIVE%$OEM$ they won't work. Maybe they could if you : SET CDDRIVE=U:\$WIN_NT$.~LS\ but it all depends of the contents of the batches. jaclaz

Let me answer this way : files bigger than 4Gb are NOT allowed on FAT16 filesystem files bigger than 4Gb are NOT allowed on FAT32 filesystem files bigger than 4Gb ARE allowed on NTFS filesystem Read NO as an answer to your question. BUT there are a few Registry changes you can make to reduce the writes on the NTFS filesystem. Here is a list (only some apply to your case): http://www.boot-land.net/forums/index.php?showtopic=6564 jaclaz

What jaclaz means is less "philosophic" than anything else in this thread. Using the approach in the given links works. I don't care if it's TOC related, LBA related or whatever related. (but it's LBA related ). It is not strictly "ISO" related. It works on CD and on "normal" filesystems, and on any media, of course on fast media (internal hard disks) difference is much LESS noticeable. jaclaz

Yep, point is just: WHY F8? There are "special" MBR's that can change while booting the Active and Hidden status of partitions, usually they use F9 or F10. Read these: http://www.boot-land.net/forums/index.php?showtopic=6830 http://www.boot-land.net/forums/index.php?showtopic=6865 http://www.boot-land.net/forums/index.php?showtopic=6893 AND links in them. jaclaz

That would be a great thing. I have a few PM's by people who don't know English very well, so I'm trying to find the time to translate existing guide (into Italian), but I am a bit reluctant as this "kind" of people tends to be also not particularly "tech savvy" and the procedure is fairly complex for the newbie, and the risk of somehow "frying" the drive by mistake is great. Having something along the lines of what I hinted here: http://www.msfn.org/board/index.php?showto...28807&st=48 tested and working, could make the difference. About the other point, of course you are free to choose your way, but: jaclaz

Victoria Looky here: http://www.benchmarkhq.ru/english.html?/be_hdd.html jaclaz

Sorry to say so , but that's not really a "valid" argument, as I (and some other people) see it : http://homepages.tesco.net/J.deBoynePollar...ess-metric.html jaclaz

The "Dietmar's way" XP install on USB is already fairly portable. BUT, of course there may be problems with device drivers. I have never had the time/will/need to do experiments, first thing that come to mind is the use "by default" of UNIATA and UNIVBE, in this only seemingly completely unrelated thread: http://www.911cd.net/forums//index.php?showtopic=21711 there are some links Or add the entire set of driverpacks....but the build will grow in size. Another approach, for which I seem to completely fail to find interested contributing members is the XPCLI project, utterly and fully experimental and unfinished: http://www.boot-land.net/forums/index.php?showtopic=3717 In it's (future) XPCLINL evolution, it may be what you are looking for: http://www.boot-land.net/forums/index.php?...=3717&st=31 As a side note project evolved (or involved ) into yet another unfinished thingy: http://www.boot-land.net/forums/index.php?...c=6393&st=0 jaclaz

Counter-productive to what? If the "base idea" from the good guys at MS is to NOT let people run NT based systems on USB flash devices, by: making FAT32 slower making "common" flash based devices unpartitionable (with the "Removable" vs. "Fixed" bit) in the controller failing to supply a Filter Driver to workaround above pushing NTFS as the preferred filesystem (and thus heightening the risk of premature wear) it seems to me like they did a VERY good work.... jaclaz

Yep , and we don't even have a clear idea on WHICH events are logged and HOW MANY such events take place in an "average powered on hour". If, as it has been hinted/reported somewhere on the threads, a S.M.A.R.T. query raises an event that is actually logged, we will soon fall in the paradox that the more you check your hardware status the more prone it is to fail..... Additionally, supposing that certain commands create multiple entries (or "sets" of entries) it is debatable whether "320" has more or less probabilities to be reached. I mean how probable it is with a "random" number of arbitrary "sets" ( say resulting in 1, 2, 3 or 4 log entries) to reach exactly 320 or to miss it, like in: I don't think we can find an accurate answer , but we can say that we are definitely NOT in an Infinite Improbability Drive (pardon me the pun ): http://en.wikipedia.org/wiki/Sub-Etha#Infi...obability_Drive but rather near, VERY near normality (1:1).... jaclaz

A FAT16 formatted 4GB filesystem will use "non-standard" 64Kbyte clusters, it may be speedier, but highly inefficient: http://www.msfn.org/board/index.php?showtopic=110779 and non compatible with "standard" DOS GOOD question. No pre-made answer, though. Probably, but cannot say, disabling SFC/WFP and replacing the "new" driver with the "old" one may work, but not only cannot say, I don't even know in WHICH driver lies the difference, possible candidates : fastfat.sys disk.sys usbstor.sys usbhub.sys usbehci.sys (usbohci.sys) (usbuhci.sys) and it could also be a "combined effect".... jaclaz

To put it bluntly, NO. Victoria may help you in determining if you are experiencing the particular problem. (i.e. help in diagnosing it) Once you are reasonably convinced that your problem is that problem, you'll have to read what fatlip suggested and see if the procedures described there (NOT easy, NOT for the "total newbie") apply to your case. Alternatively you may want, after having read the related threads, to contact Seagate support, things are moving on, and it is very possible they will recover your drive for free. jaclaz

Yep , the point I was trying to make was that if you can go in a few "logical" steps from 100÷150 reports here on MSFN to a bare minimum of 20,000, rounding everything by defect and using largely speculative "safety" factors, we can say, rightfully and without fearing to be proved wrong by actual figures (when and if they will come to the light), that the phenomenon is HUGE. Which does not mean it's a matter of millions (though it might be ) but enough to allow me to say that the known title is incorrect: as the issue does not appear that much overhyped (read not at all ) and it's definitely not FUD. Using Dirk Gently's I-CHING calculator: http://www.thateden.co.uk/dirk/ anything resulting above 4 becomes "A Suffusion of Yellow", on my personal calculator anything above 20,000 results in "lots" or "too many to count". I don't care if they represent "only" "some percentage of the drives". Besides, dlethe while advises the use of common sense: In his article: http://storagesecrets.org/2009/01/seagate-...-overhyped-fud/ seems to be lacking the same. As long as we are "talking adjectives", everyone is free to have it's own stance and definitions, but when it comes to probabilities and calculating them, checking twice the math would be advised. Compare the "cryptic" explanation of the "magic number": With the one reported from Seagate: Since I guess that this latter info was available to dlethe in his "under NDA" documentation, let's see how many x's we have in 16 bit number : We have 65,536 values, possibly from 0 to 65,535. In this range, maximum x can be found by resolving: 320+x*256=65,535 Thus: x*256=65,535-320 x=(65,535-320)/256 x=254.7461 => 254 (plus the 0 value, i.e. "plain" 320 case) => 255 possible values for x This would place the odds to 65,536:255 => i.e. roughly to 257:1 instead than the proposed "> 65,000:1" Which would mean that the initial calculation was grossly underestimated. Again, it is possible that today is not my "lucky" day with math..... jaclaz

See if this helps: http://www.msfn.org/board/index.php?showtopic=128727 Maybe you'll become a happy bunny yourself. jaclaz

I would try XP rather than 2003, and would also nlite it. I would also try with a "gold" or SP1 XP rather than SP2 or SP3. About the error, possibly is similar to this one: http://support.microsoft.com/kb/330182/en-us jaclaz

FYI: http://www.911cd.net/forums//index.php?showtopic=20314 OP "abandoned" the game, but some info may nonetheless be useful. jaclaz

Well, there are exceptions needed to confirm the rule..... Just for your entertainment : http://www.boot-land.net/forums/index.php?showtopic=3541 http://www.jazzkeyboard.com/jill/qarticles.html jaclaz