jaclaz

I am sorry if I added to the confusion, I simply posted two examples with "direct" and "inverse" logic. jaclaz

It's strange as it works here (of course with another printer name). Can you try running this simplified version (change "PDFill" with that TOSHIBA printer, but try also with another one). THe output here is (correctly): Could it be that accented characters make an issue? Like é, è, etc? jaclaz

Hmmm. Try entering this on command line (NO IF's): type qwertymnbvcxz >nul 2>&1 &&ECHO You won't see this Then: type qwertymnbvcxz >nul 2>&1 ||ECHO You will see this @JFMichaud TRY this (your original one should work, though ): Post the output of reg query "HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Devices" maybe there is a typo somewhere.... jaclaz

Then it is possible that the MFT settings in the Registry is ONLY read on initialization of some filesystem-related DLL. The "final test" would be to put a "hook" on it with Regmon/procmon and create a boot-time log. Sure there are, the issue is that AFAIK : the product must be listed among those "open for suggestions" they won't probably ever reply to you they most probably won't even listen to your suggestion in any case, no matter how valid the suggestion will be, chances it will be actually implemented depend on "random" factors http://connect.microsoft.com/ Good luck! jaclaz

Oh, oh Logical impossibility detected ! *Any* "serious computer freak" will ALREADY know about MSFN.... You are either harassing real "serious computer freaks" with redundant info or recommending MSFN to "frivolous computer freaks" jaclaz

Interesting results. Maybe defrag . I found it "queer" that a reboot is needed/mandatory. The $MFT zone reservation is something that make little (or no alltogether) sense in "normal" use while it may make some sense on Servers (which are exactly those that you would *never* re-boot), but - generally speaking - I would never use "make sense", "obvious" or "natural" in the same sentence with anything made by the good MS guys , it is very possible that these features (or lack of) are by design: http://reboot.pro/3541/ jaclaz

This appears to be similar to the known approach to the 7200.11 ES2 , shorting the "read channel" (whatever it is ) to access terminal: http://translate.google.com/translate?hl=it&sl=ru&tl=en&u=http%3A%2F%2Fpeople.overclockers.ru%2Fshowman%2Frecord1 The integral post from seagate board (just in case ): jaclaz

Hmmm : What about D-link? http://www.dlink.com.au/tech/Download/download.aspx?product=DBT-122&revision=REV_C&filetype=Drivers ftp://files.dlink.com.au/products/DBT-122/REV_C/Drivers//DBT-122_C_Driver_5.1.0.1100/DBT-122_C_Driver_v5.1.0.1100.zip or EMTEC?: http://www.emtec-international.com/en-eu/old_drivers http://www.emtec-international.com/sites/default/files/drivers/driverbluetooth.zip WARNING! Senselessly HUGE packages, tens of Mbytes!. (the above are Widcomm) jaclaz

Then why your profile says that you are from the U.S.? You should NOT use methods for 7200.11 on a 7200.12, and definitely NOT use *any* command unless you find out the state the disk is! You were probably lucky that you had the errors and thus you were prevented to do further damages. Yes, that is an average price. Real issue is finding a reliable data recovery firm. Your chances are EXACTLY 0 (zero). There is a sticky in the Forum: http://www.msfn.org/board/forum/169-hard-drive-and-removable-media-issues/ (which is where you should have actually posted: MSFN Forum > Software, Hardware, Media and Games > Hardware Hangout > Hard Drive and Removable Media issues that applies to 7200.12 too. All modern drives need some info that is stored in a chip on the PCB and this innfo is "coupled" with the actual disk drive, if a PCB has failed then it is possible to do a PCB swap BUT the chip needs to be "transplanted" from the old PCB to the new one. It is possible that the disk is still recoverable BUT we don't have a "verified" sequence of commands for the 7200.12, if not these ones: http://www.facebook.com/note.php?note_id=152456431478526 http://computersciencelabs.blogspot.com/2011/02/seagate-720012-sim-error-firmware-fault.html BUT the problem here is that we have NO idea in which exact condition is now the disk (set aside if due to an initial problem, the failed firmware update, your attempts, or *something else*) . Post the EXACT error message you have when connecting through terminal. (maybe some kind soul will be able to help you) Take your time reviewing ALL the above mentioned posts/references, think a lot BEFORE issuing any of the mentioned commands, take your chances. DO NOT, and I mean DO NOT attempt using the "m0,1" command unless you find any RELIABLE source advising it. jaclaz P.S.: BTW it seems to me like you already took your chances on hddguru forum: http://forum.hddguru.com/maxtor-stm3500418as-dead-after-failed-firmware-update-t18265.html and you were already told at length how doing a PCB swap cannot possibly work.

The "normal" sequence at power on is AFAICU something along the lines of: read *something* from the onboard ROM spin up read *something else* from the actual disk platters present to the BIOS query some data If the disk does not spin up it simply cannot read part of the information, it gets into a "busy" or BSY state and as such the BIOS won't detect it. The symptoms could be - with the same possibility - a stuck bearing or a head stuck. If the first, in some rare cases it can become free with either percussive maintenance or with the "freezer trick". If the second it is more likely that it can be freed with some percussive maintenance BUT it is very likely that you will have a head crash. To have an idea of the force that is needed to free a stuck bearing (if really stuck) check this: And this to understand what happens with stuck heads: jaclaz

Well, what you asked a few posts above was: The answer is yes, two suitable applications (for two different OSes ) were suggested to you. Whining about how much earthlink supposedly sucks and what they should provide as feature to their users may possibly result in something if told to them. jaclaz

Just for the record, under LInux there is Napalm: http://www.scarpaz.com/Napalm/ A window app having (among others) a similar feature is this one: http://www.poptray.org/ jaclaz

Well, maybe looking in it's License (the one that you have to read BEFORE ticking "I accept" when installing), would help: jaclaz

From what you report that drive does not spin UP. Check if it does first thing: If it does not, the ONLY possibility you have (VERY, VERY, VERY risky for the integrity of the drive) is some "percussive maintenance": In a limited (very limited amount of cases, holding it in a vertical position may be enough to allow initiating the spinning. jaclaz

I have no idea , ideally you should try by steps: CHKDSK CHKDSK /F CHKDSK /X (only Windows 2003 and later) I would "bet" on CHKDSK /F, but it is possible that CHKDSK only is enough. Another test would be simply UNmounting the volume and re-mounting it. I would try first with MOUNTVOL (available since NT or 2K) On Server 2008 and 7, another approach could be setting offline the actual disk: http://reboot.pro/8200/page__st__39 If you prefer, I suspect that the reboot is not vital but having CHKDSK check the volume or Mount Manager re-discover it should be enough for the new MFT reservation to be enabled. And yet another test could be defrag. jaclaz

Happy there is (yet another ) happy bunny in the basket. http://www.msfn.org/board/index.php?showtopic=128727&st=10 jaclaz

Sure . The idea of an example is that of an example. IMHO, not that of a "refined" solution. jaclaz

Then you have an example to work on. jaclaz

Do you want to remove it or change it to something else (and if this is the case) is the something else "fixed" or variable? I.e. C:\program files\GnuWin32\bin\www.slv.dk\Dokumenter\dsweb\Get\Document-1413\_K_ENR_1_6_en.pdf should become: 1_6_en.pdf <somethingelse>1_6_en.pdf Example (remove _K_ENR_ only ) @ECHO OFF SETLOCAL ENABLE EXTENSIONS FOR /F "tokens=* delims=" %%A IN ('DIR /B /S *.pdf') DO CALL :rename "%%A" GOTO :EOF :rename SET filename=%~n1 SET Newfilename=%filename:_K_ENR_=% ECHO %1 ECHO "%~dp1%Newfilename%%~x1" GOTO :EOF jaclaz

If I get it right, what you are wanting to build is - more or less - a "car PC", only you will use it in your dining room instead. So, this might be the right place to get some ideas: http://www.mp3car.com/vbulletin/ jaclaz

It seems to me perfectly "natural". You have an EMPTY volume. You tell the OS to expand the MFT zone. It finds a lot of free space ("on the right") to expand the MFT zone, it does it. Of course there is NO need whatsoever to reformat. The tests should be made with a "filled" volume (actually all is needed is to have a few files right after the previously set MFT reserved zone. But in this case there will be no need to reformat, most probably the files will be moved "further on the right". A nice experiment could be instead of rebooting to run CHKDSK on the volume. Tools mentioned here may come handy: http://reboot.pro/15086/page__st__25 jaclaz

Have you followed to the letter the instrutions in the thread: particularly: The file TEE.BAT is exactly where it should be inside the .zip, and I see no reason why it shouldn't be there when the achive is unzipped. jaclaz

Well, actually 786432 is a reather largish number to have those properties. 64x1024=65536 would do as well. If I recall correctly (though not as low as the above) wWin2K used a much lower address for the $MFT. As I posted earlier (corrected, there was a lapsus calami), on an 8 Gb volume in XP the MFT goes to And we have: 786432*8=6291456 6291456*1=6291456 3145728*2=6291456 1572864*4=6291456 Quick test just made: Image Bytes/ Sectors/ $MFT $MFT Offset size Cluster Cluster Cluster (sectors) 1 Gb 1024 2 349525 699050 2 Gb 2048 4 524288 2097152 3 Gb 4096 8 262144 2097152 4 Gb 4096 8 262144 2097152 5 Gb 4096 8 262144 2097152 6 Gb 4096 8 786432 6291456 The "switch" is between 5 and 6 Gb. jaclaz

I guess there is a misunderstanding. I am not saying that a same volume size with different cluster size will always hold the $MFT @#786432. I am saying that the *normal*, default NT format will tend to create the $MFT @#786432, or, if you prefer, that *all* NTFS volumes/bootsectors I ever examined had the $MFT @#786432 in the bootsector field, starting form a certain size. It is very possible that this "fixed address" behaviour is not cluster #786432 x 4 kb (default cluster size for a rather largish range of volume size): http://support.microsoft.com/kb/140365/en-us but rather offset 786432 x 4096=3,221,225,472 or sector 6,291,456 and that this is not affected by cluster size. You can check this directly (instead of using Ultradefrag) by checking the 16 bytes @offset 0x30 in the bootsector and multiplying for cluster size (single byte @offset 0xD) or using (as an example) tiny hexer that has a built in Structure Viewer for NTFS bootrecord (and optionally using my INCOMPLETE - but working for theis NTFS fielsds - one): http://reboot.pro/8734/ jaclaz

Interesting report! : JFYI : http://support.microsoft.com/?id=961095 Translated from MSish to layman's terms: Seriously, now, my experience with the location of $MFT is different, when a given size is reached the offset becomes "fixed" to cluster #786432 or 0xC0000. jaclaz