jaclaz

I guess that all credits should go to os2fan2 that wrote the batch snippet that you just posted almost verbatim. (or at least I seem to fail noticing any difference worth mentioning) : jaclaz

Well, Fernando has is own thread right here (he has an undercover nick of Fernando 1 here on MSFN ): http://www.msfn.org/board/index.php?showtopic=107504&hl= jaclaz

On the contrary I seem to be the only one making a distinction. In my personal judgement not only the guys at i365 , but also the Seagate engineers are good guys after all, as said an hiccup can happen to everyone, they made a mistake, ok, but they made several other drive models working fine, if they would simply make some public excuses I would forgive them allright. What I find simply awful are the behaviours of (in no particular order) : Seagate Marketing and Company Executives (for trying to deny the evidence for months and later trying to severely underestimate the phenomenon) Seagate Assistance and Customer Care (for simply lying to Customers for a considerable amount of time and for often giving deceiving and incorrect information - and this behaviour has not yet ceased) Seagate Forum Administrator and Mods (for applying senseless censorship deleting reports in the desperate effort to minimize or hide the problem) Seagate Press Office (for avoiding replying to many legitimate questions of bloggers and on-line magazines) Most probably the Company was afraid of another Class Action, like the one they already had: http://apcmag.com/seagate_settles_class_ac..._capacities.htm There were rumours about a (supposedly reknown) Law Firm willing to start such an action: http://www.bluescreenofdeath.org/?p=91 though the actual said Law Firm site is (alas?) no more : http://www.kbklawfirm.com/seagate/index.php CACHE: http://209.85.129.132/search?q=cache:rPRvR...mp;client=opera EXPIRED: http://whois.domaintools.com/kbklawfirm.com (please note the date it was first created - I like coincidences ) http://gizmodo.com/5130702/1tb-seagate-bar...-gogo-users-say http://www.electronista.com/articles/09/01...acuda.failures/ http://www.theinquirer.net/inquirer/news/1...7200-11-failing Pretty quick guys over there in Denver.... Nonetheless the Company should IMHO be brought to court for the described misbehaviours. jaclaz

Actually you DO NOT need to. Copy the snippet in a NOTEPAD file, save it with a .cmd extension. Make sure to change this line: to the actual path of your \i386 directory (copied from Cd to hard disk) Make sure to put reg.exe in the same folder where you save the file. Double click on the .cmd file in Explorer. Or you can use REGEDIT manually allright. jaclaz

...should kumarkumar be willing to follow the advice he asked for..... jaclaz

...wait until you get here: http://www.msfn.org/board/index.php?showto...807&st=2323 The linked to post was the consequence of a number of reports about people that were told by Seagate that : they would have NOT attempted Recovery of the data they would EITHER recover the sent drive OR send back ANOTHER working one they would NOT refund ANYTHING BUT a working drive should the sent drive be lost or damaged during shipping forth and back they would provide DATA Recovery through i365 at a cost ranging from $300 to $600 I am happy to know that the good i365 guys, when contacted directly, provided a different arrangement. BTW, how much was the total cost? Or was it ALL at Seagate's or i365's expenses, including the shipping back and forth? This said, I personally find the risk of damage or lost during the shipping to be very high, if you have ever seen how packages are usually handled in airports or storehouses you know what I mean , and in my view higher than that of fixing at home. About this: unfortunately the "because" is moot, you should NEVER, and when I say NEVER, I do mean NEVER, trust ANYONE with the safety of your data. This time it happened to Seagate, but each and every maker has had some "bad" model, and in any case, even if you get a "perfect" drive, there is ALWAYS Murphy's Law around, trying to prove itself right. Having data on a single media, no matter the manufacturer, is very, very, VERY risky. ALWAYS make multiple copies, two at the very least, three much better, of ANYTHING you think of value. jaclaz

and as well not really universal, but covering a certain number of SATA's: http://www.boot-land.net/forums/index.php?showtopic=2384 http://alter.org.ua/en/soft/win/uni_ata/ jaclaz

With all due respect for the Owners and Admins of the board , they do seem to have a twist for changing the way links work (or completely fail to). However it's post #18 in this same thread. See if these work: http://www.msfn.org/board/index.php?showto...75713&st=17 http://www.msfn.org/board/index.php?s=&amp...st&p=590337 jaclaz

Define fastest: fastest to prepare source for fastest to deploy Define running OS (where you prepare the source): 2K XP/2003 Vista/2008 Windows 7 Define target machine available RAM: 512 Mb or less 1 Gb 2 Gb (or more) And possibly you will have a non-silly answer. jaclaz

NO. That line would give a title of "%USERPROFILE%\Desktop" to the window. The "/h" is a paremeter to "some.exe". Read again the given link. command means the name of executable, including a fully qualified path to it UNLESS: the program is in the SAME directory as the running batch the program is anywhere in the PATH A GENERAL rule about command line and batch parsing is that the SPACE is a separator, thus a full path containing spaces MUST be enclosed in double quotes. A workaround is using 8.3 compliant names, but this can generate "colliding" paths. (hint: use DIR /X) Don't be tricked by the optional [/Dpath] option that sets the "working directory", not the target to be executed. jaclaz

Well, I can recommend doing baby steps, just copy and paste this: Sub CountQualifiedLines() Dim CharCount As Integer Dim tCount As Integer Dim LineCount As Integer Dim Qualifier As String Qualifier = InputBox("Enter minimum line length:", "Line Length", 1) tCount = ActiveDocument.ComputeStatistics(wdStatisticLines) Selection.HomeKey wdStory Do While tCount > 0 Selection.EndKey Unit:=wdLine, Extend:=wdExtend CharCount = Selection.Characters.Count tCount = tCount - 1 If CharCount > Qualifier Then LineCount = LineCount + 1 End If Selection.Collapse wdCollapseStart Selection.MoveDown Unit:=wdLine, Count:=1 Selection.EndKey Unit:=wdLine, Extend:=wdExtend Loop Selection.HomeKey wdStory MsgBox "There are " & LineCount & " qualified lines in this document" End Sub In a new module in a Word Document (already containing some text). Run the Macro. See what it does, and study the code. (Hint1: You don't need a FOR loop, the example does a "countdown" from the total number of lines in the document down to 0) (Hint2: Anything following a Dim statement is a variable) jaclaz

No, you don't need a patched SETUPREG.HIV. You need to patch your SETUPREG.HIV, READ here: http://www.msfn.org/board/48-bit-lba-win2k...13-page-17.html The batch will ONLY set the appropriate keys, leaving all the other ones (including the ones related to the version) as-they-are-now. jaclaz

You don't have a problem with the USB booting, you have a problem with booting in Protected Mode, when text setup "switches" to it. Sometimes it can be solved by using a modified NTDETECT.COM, FAQ's (Frequently Asked Questions) are there exactly for this scope, check #3 here: http://www.msfn.org/board/faqs-t116766.html They should be actually called FGA (Frequently Given Answers) but call them how you like, they should be ALWAYS READ before asking what's already covered in them And BTW : Yes. http://homepages.tesco.net/J.deBoynePollar...no-answers.html jaclaz

Paying a ransom? Naaah, better trying TESTDISK on it (if the filesystem structures are still good - which I doubt if you overwrote it by installng Windows 7 on it) or PHOTOREC (for file based only recovery): http://www.cgsecurity.org/wiki/TestDisk In any case it is STRONGLY recommended that you image the drive on another one; if you need to use PHOTOREC you will need ANYWAY another hard disk to store the recovered files. jaclaz

Some ideas: http://technet.microsoft.com/en-us/library/ee692861.aspx http://vbcity.com/forums/p/146575/628427.aspx And some real world Macro examples: http://web.ticino.com/multilingual/word_ch..._count_tips.htm http://gregmaxey.mvps.org/Count_Lines_of_Text.htm The second example in the latter should be a good base for you. jaclaz

@soarinblue I do understand that most of the board is dedicated to help not-very-expert people and that one should be very gentle with them. As well I perfectly know that "common sense" is one of the least common things around. You BLOCKED the present Board thread by posting in three subsequent posts three logs by copying and pasting them inside your posts! For the record, first one is 1,590,262 bytes long, second one is 1,592,324 and the third one (since you "reduced" it as being bigger than 200Kb) is a mere 43,502 bytes. Please find ATTACHED, NOT, and I mean NOT pasted inside a post, your three files COMPRESSED in a .7z archive, totaling 66,781 bytes. Next time, please ask how to send a file BEFORE posting two of them, each over 1.5 Megabytes! It took me more than half an hour and had to use all the tricks of the trade +1 to be able to access the thread and fix the mess you created. jaclaz soarinbluelogs.7z

Actually it has a simplified sintax, look: dd [bs=SIZE] [count=BLOCKS] [if=FILE] [of=FILE] [seek=BLOCKS] [skip=BLOCKS] [--size] [--list] [--progress] semplified to: dd [if=FILE] [skip=BLOCKS] [count=BLOCKS] [of=FILE] TO copy the MBR of hard disk 1 (Second hard disk) to file C:\mymbr1.bin: dd [bs=512] if=\\.\PhysicalDrive1 skip=0 count=1 of=C:\mymbr1.bin Example of output: C:\VSS>dd /? rawwrite dd for windows version 0.5. Written by John Newbigin <jn@it.swin.edu.au> This program is covered by the GPL. See copying.txt for details Unknown command /? dd [bs=SIZE] [count=BLOCKS] [if=FILE] [of=FILE] [seek=BLOCKS] [skip=BLOCKS] [--s ize] [--list] [--progress] SIZE and BLOCKS may have one of the following suffix: k = 1024 M = 1048576 G = 1073741824 default block size (bs) is 512 bytes skip specifies the starting offset of the input file (if) seek specifies the starting offset of the output file (of) C:\VSS>dd if=\\.\PhysicalDrive1 skip=0 count=1 of=C:\mymbr1.bin rawwrite dd for windows version 0.5. Written by John Newbigin <jn@it.swin.edu.au> This program is covered by the GPL. See copying.txt for details 1+0 records in 1+0 records out The same using dsfo: dsfo \\.\PhysicalDrive1 0 512 C:\mymbr1.bin Example of output: C:\VSS>dsfo dsfo v1.03-CLI, Freeware - use at your own risk (c)2005 Dariusz Stanislawek, http://freezip.cjb.net/freeware Usage: dsfo source offset size destination Note: null size is interpreted as max possible output negative size is calculated on current file size negative offset is calculated from end of file use "$" as destination to check MD5 signature only Example: dsfo c:\tmp\my.avi -50000 0 test.bin dsfo \\.\d: 0 512 c:\0\partition-sectors.dat dsfo \\.\PHYSICALDRIVE0 0 0 \\srv\shr\tmp\first.dsk dsfo \\.\a: 0 0 "c:\tmp\floppy disk image.img" dsfo \\.\e: 0 0 d:\CDROM_or_DVD_image.iso C:\VSS>dsfo \\.\PhysicalDrive1 0 512 C:\mymbr1.bin C:\mymbr1.bin - Existing file. (dsfo, UNLIKE dd will NOT overwrite an existing file) C:\VSS>del c:\mymbr1.bin C:\VSS>dsfo \\.\PhysicalDrive1 0 512 C:\mymbr1.bin OK, 512 bytes, 0.000s, MD5 = fc5ffca90519daa9c9c8d5dfeb7911a4 jaclaz

Optimism is your not strong point, I presume. You should separate the problem in two parts: 1) unbricking the drive 2) updating the firmware The worst thing that can happen with #1 is that the procedure doesn't work (and then there is no reason to worry about #2), but it is unlikely given the number of people that reported success. Of course it is well possible that the problem of your drive is NOT related to the issue that the procedures try to fix (0LBA oer BSY due to the 320th log entry. On the other hand, if you succeed with #1 the ONLY thing that you should do in your right mind is FORGET about the firmware, get all the data you can off the stoopid seagate and put it on another disk, then the seagate will have NO value whatsoever, and you can do all the experiments and tests you want with it, again, even if the Firmware update is successful, DO NOT trust that drive. However, and since you asked: judging also from your other post here: http://www.msfn.org/board/instructions-che...63.html&hl= You are approaching it the "wrong" way. You are a bit pessimist/overcautious BUT: you are going to use a non-supported OS (Windows 7 instead of XP/2003) you are going to use a known to be a possible failure hardware (the CA-42): you don't trust yourself but are willing to trust a stranger that says he is able to do recover for you and give him your drive The suggested approach is: use the OS that has been reported to be working for sure (XP/2003) use one of the TTL adapters that have been reported to be working for sure trust ONLY yourself and/or a friend of yours technically oriented or a professional The "main" thread is full of people who reported success with one or the other method and practically noone reporting an "absolute" failure, i.e NO hints that performing the procedure has damaged a drive even when it failed to unbrick it. jaclaz

It's a simple one way switch, you either try WD-40 or a similar contact cleaner or you simply connect the two pins to which the microswitch is connected on the motherboard with a loop of wire. But it should not affect external displey. Cannot say more without a better description of what is happening, but it does smell like a "real" hardware problem (fried videocard). jaclaz

YES. http://homepages.tesco.net/J.deBoynePollar...no-answers.html Read post #8 above, and all the following ones, for good measure, and particularly #11. Replace the call to diskpart with a call to your interactive batch or other disk management utility. jaclaz

Great! jaclaz

This is gonna be tricky business. It is possible that something has changed in the drive (something at a low enough level to be not a problem on a non-raid setup, but high-level enough to be detected by the controller). It greatly depends on the controller and the utilities that come with it, but AFTER having made a forensic sound (dd-like byte by byte copy of each and every disk) you could try forcing the failed drives online, there should be a way to do so. It is also possiblre to re-assemble the data, example: http://www.freesoftwaremagazine.com/articles/recovery_raid a Commercial app: http://www.runtime.org/raid.htm that has a demo capable of telling you if the "full" version will be able to recover the data. DO NOT EVEN THINK of doing any work on those drives before having imaged them. jaclaz

Thank goodness, then I can sum the + 667 I got on another one and have an average of 261.50 jaclaz

Well, no. I mean the idea was to try using showdrive.exe or mountstorePE INSTEAD of mnt.exe. mnt.exe needs to be given "arguments", showdrive.exe or mountstorePE will IF they find a device not mounted to a drive letter to mount it. jaclaz

Nice. jaclaz