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

Now an English grammar question (provided that the answer was written by a mother tongue English speaking executive, possibly with some Law background besides technical and mathematical knowledge). How much is "only some percentage"? Let's see, if they were in total a few hundreds, say 800, i.e. 7 or 8 times the number of serials published on MSFN. Let's also assume that the affected drive models are 1/3 of past year production. According to dlethe: Seagate is running for 1,000,000,000 disk drives annually, I guess that extimating 2008 production at 1/3 of that number would be prudential. So let's try the math: 1/3*1,000,000,000= 333,333,333 drives produced in 2008 1/3*333,333,333=111,111,111 drives of the said to be affected models in 2008 Let's round this number by defect to 100,000,000. now, let's say that 0,2% is the minimum that can be defined "some percentage" (if it was less than this, anyone in his right mind would have used a definition like "a fraction of percentage" or "less than a single percentage point" or something "diminutive" like that) now: 0,002*100,000,000=200,000 OK, figures above may be exagerated/wrong, let's introduce a 10 times "safety factor": 200,000/10= 20,000 Anything between 20,000 and 200,000 appears "reasonable". Even taking the lowest of the "range", 20,000 is several times bigger than the initially assumed 800. Is it one of those days where my understanding of English is failing AND my math skills lack any kind of precision? jaclaz

Hmmm. Expecially in a Corporate Environment, I would DOUBLE check if you are allowed to "join two planks": http://www.911cd.net/forums//index.php?sho...9355&st=134 Also, I think this KB is still valid. http://support.microsoft.com/kb/935467/en-us jaclaz

On the bright side, how many "Autovelox", "Speed Cameras" or similar Speed checking devices of the last generation went beserk, lowering the chances of you getting fined? Another way : http://gizmodo.com/5069422/the-muppets-ani...ng-police-crazy jaclaz

You'd better get an informed consent module signed, then: http://en.wikipedia.org/wiki/Informed_consent jaclaz

More generally the two directories are created also when installing windows through WINNT.EXE and WINNT32.EXE. And they are also used on the now becoming historical "multiboot CD/DVD" guide : http://flyakite.msfn.org/ The names are hardcoded by the good MS guys, and while BT is obviously short for "BooT files", LS origin is unknown AFAICR. @siginet @wimb You both may want to look at the newish two features of grub4dos: dd ****************************************************************************** *** New command 'dd' to copy files *** ****************************************************************************** Usage: dd if=IF of=OF [bs=BS] [count=C] [skip=IN] [seek=OUT] Copy file IF to OF. BS is blocksize in bytes, default to 512. C is blocks to copy, default is total blocks in IF. IN specifies number of blocks to skip when read, default is 0. OUT specifies number of blocks to skip when write, default is 0. Skipped blocks are not touched. Both IF and OF must exist. Both IF and OF must have a leading device name, i.e., of the form `(...)'. You may use `()' for the current root device. dd can neither enlarge nor reduce the size of OF, the leftover tail of IF will be discarded. OF cannot be a gzipped file. If IF is a gzipped file, it will be decompressed automatically when copying. dd is dangerous, use at your own risk. To be on the safe side, you should only use dd to write a file in memory. In some cases when writing a file in NTFS, dd might fail. If you attempt to write a file that is not in memory by starting dd in a menu, you will safely be refused :-) !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~!!!! !!!! Caution! Both IF and OF can be a device name which stands for !!!! !!!! all the sectors on the device. Take utmost care! !!!! !!!!______________________________________________________________________!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! and write ****************************************************************************** *** Use 'write' to write a string into a device or file *** ****************************************************************************** Usage: write [--offset=SKIP] ADDR_OR_FILE INTEGER_OR_STRING SKIP is an integer and defaults to 0. If ADDR_OR_FILE is an integer, then it is treated as a memory address, and INTEGER_OR_STRING must be an integer value. The integer INTEGER_OR_STRING will be written to address (ADDR_OR_FILE + SKIP). If ADDR_OR_FILE is a device or a file, then INTEGER_OR_STRING is treated as a string which will be written to ADDR_OR_FILE at offset SKIP (in bytes). The string is quoted with nothing, that is, neither with the single quote char(') nor with the double quote char("). Space char must be quoted with back slash(\). Single quote char(') and double quote char(") are not interpreted specially and can be used directly in the string. Some C-style quote sequences are interpreted as follows: \NNN character with octal value NNN (1 to 3 digits) \\ backslash \a alert (BEL) \b backspace \f form feed \n new line \r carriage return \t horizontal tab \v vertical tab \xHH byte with hexadecimal value HH (1 to 2 digits) Just like dd, the write can neither enlarge nor reduce the size of the destination file, the leftover tail of the string will be discarded. The destination file cannot be a gzipped file. Again like dd, the write command is also dangerous, use at your own risk. And to be on the safe side, you should only write to memory files. In some cases when writing a file in NTFS, the write might fail. If you attempt to write a file that is not in memory by using write in a menu, you will safely be refused :-) !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~!!!! !!!! Caution! The file to write can be a device name which stands !!!! !!!! for all the sectors on the device. Take utmost care! !!!! !!!!______________________________________________________________________!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Still experimental, NOT recommended for "production" right now, but worth some time considering. @wimb Additionally, check the new uuid: ****************************************************************************** *** New command 'uuid' to identify partitions *** ****************************************************************************** Usage: uuid [DEVICE] [UUID] If DEVICE is not specified, search for filesystem with UUID in all partitions and set the partition containing the filesystem as new root (if UUID is specified), or just list uuid's of all filesystems on all devices (if UUID is not specified). If DEVICE is specified, return true or false according to whether or not the DEVICE matches the specified UUID (if UUID is specified), or just list the uuid of DEVICE (if UUID is not specified). Example 1: find --set-root uuid () 7f95820f-5e33-4e6c-8f50-0760bf06d79c which will find a partition with uuid=7f95820f-5e33-4e6c-8f50-0760bf06d79c and set the partition as root if found. Example 2: uuid () which will print the uuid of the current root device. That could be useful to "identify" the stick without the need of a "tag" file. @siginet GOOD work! jaclaz

Not actually the "offset". The "320" is not at all "very hidden", being on slashdot since a few days: http://it.slashdot.org/article.pl?sid=09/01/21/0052236 Now that the problem, one way or the other, has come to the open, and mostly thanks to Gradius2 and a few other members of the board , we can see the light at the end of the tunnel , notwithstanding the poor way Seagate managed the issue, I would like to spend a few words against the argument of "few cases out of millions drives produced/sold": There are actually only TWO possibilities: it's actually a case of few tens or hundreds out of millions, and if this is the case providing recovery would cost proportionally next to nothing to Seagate and should have been offered since day one there are more drives affected than those listed here on MSFN, in which case a public announcement and recall campaign would have been more than justified Though of course in this particular case there is no fear of danger to health or risk of injuries something like this would have been justified, as I see it.: http://www.cpsc.gov/CPSCPUB/PREREL/PRHTML97/97175.html Because of 3 (THREE) incidents reported in the US, and probably a few more in other countries, the firm recalled some 120,000 Juice Extractors The recall was published on newspapers all around the world and, far from provoking a damage to the firm it actually bettered it's public image. Even if the reason for the (few? ) failures was still under investigation, simply instructing people at technical support, forum and/or call center to reply something like: Would have been more than enough to keep a number of enraged customers calm for the time needed. And again if the problem is about a few hundreds drives, Seagate could have afforded sending a technician in a limousine to the customer home or office and apply the fix. Still generally speaking there are two ways to avoid "panic" and keep customers satisfied: deny the evidence tell the truth, provide remedies and offer excuses In this era of communication, choice 1. above is, besides immoral, unrealistic. jaclaz

Just out of curiosity, what are your expectations out of installing Vista on 256 Mb RAM? Anything more than XP on 20 Mb? http://www.winhistory.de/more/386/xpmini_eng.htm 256 is below "common sense" threshold for XP, let alone Vista. jaclaz

I had guessed that "choice" was removed since 2K thanks to "SET /P" Or are we talking about DOS? jaclaz

Just to add a bit of fuel , wouldn't this statement: http://storagesecrets.org/2009/01/contact-...overy-services/ be, to say the least, unsupported by the evidence of the number of reported successes? Or am I misunderstanding it's meaning? jaclaz

What the heck has the "HP" Drive key boot utility have to do with low-level tools? The particular one you linked to appears to be a update to the oldish: http://home.graffiti.net/jaclaz:graffiti.n...B/USBstick.html to update the firmware of some HP Proliant Servers hardware from USB stick: http://h20000.www2.hp.com/bizsupport/TechS...amp;mode=4& http://h20000.www2.hp.com/bizsupport/TechS...amp;mode=4& jaclaz

Not actually that secret "identity": http://storagesecrets.org/2/ Basically it seems, from this: http://storagesecrets.org/2009/01/seagate-...-overhyped-fud/ that the site should be called hxxp://teasing_about_storage_secrets-that_I_know_but_wont_reveal.org With reference to this: http://storagesecrets.org/2/ First suggestion that comes to mind is that, although I understand perfectly the problem with NDA's, I simply hate people telling me (or anyone else): My personal opinion is that should have Seagate managed more professionally and quickly the issues arisen and solved the problem timingly, everything would have been cool. Once that the damage is done, their only way out is to publish some (if not all) the actual reasons why that happened and public excuses to all their customers affected. The more they try to keep things secret, the more some cunning user will dig in the matter and possibly find and publish something that should not be (for security reasons). jaclaz

OT, but not much: For the record, and not wanting to seem too "alarmistic" , the reliability of 500 Gb and 1 Tb drives appears to be, to say the least, "inferior" to that of drives up to, say, 250 or 320 GB. Besides the known recent "Seagate hiccup" common also to some Maxtor's, I have seen (or heard) much more woe tales recently that in the past, it may be a coincidence or simply people making more fuss than before about dead drives, but maybe better be safe than sorry and stick to somewhat "lower density" drives. jaclaz

Most probably because yocarim didn't post any . It should be this COMMERCIAL app: http://www.extensoft.com/?p=product_info jaclaz

If when you power it clicking, clinking or rattling noises come out of the HD case, something mechanical has broken (namely heads or head arm). An external disk is nothing more than a "normal" hard disk+a IDE to USB or SATA to USB controller, as DJ MyRinX pointed out. In other words, this: http://www.usb-ware.com/tt-usb-2-hard-drive-kit.htm + this: http://www.maxtor.com/en/hard-drive-backup...hard-drive.html makes this: http://www.newegg.com/Product/Product.aspx...N82E16822100037 (more or less) jaclaz

[still_somewhat_offtopic] FYI, just came out: http://www.boot-land.net/forums/index.php?...ic=6672&hl= [/still_somewhat_offtopic] jaclaz

Just for the record, they don't appreciate bungee jumping as well.... Now, seriously. It is very possible, though indeed rather costly, to recover the data on the drive, at least partially, through the services of a professional data recovery firm. What they can do is to open the actual hard drive and replace parts in it. The procedure can also be attempted as a DIY job, but requires a number of tools and experience that, from the kind of question you asked, you appear NOT to have right now. Basically you need to find a working drive IDENTICAL to the failed one, disassemble BOTH in a "protected environment" then "transplant" some parts from the working one to the failed one, from the description of the problem most probably the heads and head arm needs to be replaced. jaclaz