jaclaz

Yep. Traditionally using "standard" software on "non-standard" setups has rarely turned out as successful. jaclaz

Expanding on this: MOST modern hard disks have a small "ROM" where parts of the firmware AND specific to the single hard disk "tuning" and "factory assigned" DATA is stored. on these hard disks does not actually mean: it actually means but, since we are talking of SMD components, doing this de-soldering/re-soldering (I mean doing it "right", without burning the chip or the board, or both and or "zapping" it in the process) is WELL ABOVE the reach and abilities of MOST people that ask the question: Moreover you have to find an EXACT (and when I say EXACT, I mean EXACT match) and anyway it is risky, even if properly done, by an expert professional. It's a nice Catch 22: People that know how to swap a PCB may ask if it is possible to do the swap. People that ask if it is possible to do the swap CANNOT do it. @BlouBul I refuse to put in the "read-me-first" such info , following this line of reasoning, I should also put in it : DON'T EVEN THINK to use a chisel and hammer if you don't have an appropriate torx screwdriver DON'T EVEN THINK to open the hard disk DON'T make a voodoo rite to revive the brick NO, dropping it from 1.12 m of height on a concrete surface won't help NO, connecting the mains to Rx and Tx won't work NO, immersing the hard disk in 12 years old whisky (single malt) overnight won't work DO NOT insert the Tx or Rx (or GND) terminals of the adapter up your nose or inside your ears etc., etc. Maybe we could make a separate sticky titled "Things that you should NOT do as they are pointless, futile or potentially dangerous" ? @momo2011 You didn't even state if you were initially affected by the LBA0 or by the BSY problem. Easy decisions path: if it is BSY do the BSY fix if it is LBA0 do the LBA0 fix (please note that the LBA0 normally means that the drive is FUNCTIONAL) if the LBA0 fix doesn't work, try doing the BSY fix first, then MAKE SURE you are in a LBA0 situation and try again the LBA0 fix If #3 above doesn't work, you are most probably in a DIFFERENT situation that is NOT (and will NOT) be covered on this thread, as it is a "non-target" (see point #1 of read-me-first) and most probably well above our heads and experience/knowledge. jaclaz

Your google-fu is low.... http://www.bttr-software.de/forum/board_entry.php?id=4713 Also Rom-Dos Defrag is claimed to be FAT32 and LFN compatible: http://web.archive.org/web/20080502215925/http://ms-dos7.hit.bg/doskbc3.htm Have you tried the FreeDOS version: http://savannah.nongnu.org/projects/free-defrag/ http://download.savannah.gnu.org/releases/free-defrag/DFRAG131.ZIP http://www.unet.univie.ac.at/~a0503736/php/drdoswiki/index.php?n=Main.Gall-DEFRAG OT , but not much , Partition Logic has also Defrag capabilities (on FAT filesystems): http://partitionlogic.org.uk/index.html jaclaz

It must be tough living with a broken google , see if you can find something yourself: http://tinyurl.com/23sa46w But, no , I don't think we have a "solution" or a "definite" one for it. You may try to use google translate on these: http://people.overclockers.ru/showman/record1 http://forums.overclockers.ru/viewtopic.php?t=295009 there may be something of relevance. Please, STOP multiposting, this thread is ALREADY filled with an excessive number of postings and NO you cannot SWAP a PCB, and NO you can NOT normally "fix" a PCB (exception made perhaps for a shot TVS diode). This is not "question time", MOST of your questions have ALREADY been asked and replied to, please TAKE YOUR TIME READing what has ALREADY been posted. IF your post is last one in a thread, ALWAYS edit it adding to it new text and NEVER make ANOTHER post just below your preceding one. jaclaz

@h2ofun Please READ before posting. momo2011 posted in this same page he self-built his converter. @momo2011 You got WHAT? jaclaz

YOU CANNOT. CHKDSK checks the filesystem, NOT the partitioning. If you have a MBR/partition table problem you may try using TESTDISK: http://www.cgsecurity.org/wiki/TestDisk Make SURE you read and learn HOW to use it before actually using it. More generally, instead of asking help for the actual problem you are having, you are currently asking help for the way you think your problem should be solved, which may or may not be the right one . Compare with these: http://homepages.tesco.net/J.deBoynePollard/FGA/problem-report-standard-litany.html http://homepages.tesco.net/J.deBoynePollard/FGA/put-down-the-chocolate-covered-banana.html jaclaz

Typically (and that is one of the reason why I won't touch ANY Symantec piece of software released in the last, say, twelve years ) Norton apps tend to write a few hundreds keys in the Registry .... There is a specific tool to remove that huge piece of bloat, if I recall correctly it is Symnrt: ftp://ftp.symantec.com/public/english_us_canada/linked_files/tsgen/ I doubt it. Another thingy worth a shot http://web.archive.org/web/20020121062439/http://powerdefrag.com/ http://web.archive.org/web/20020207182945/http://powerdefrag.com/download/PD0210B2.exe Another known "facilitator" for Win9x is "EnditAll", you can find it here: http://www.compu-docs.com/links.htm Yet another "candidate": http://www.ylcomputing.com/content/view/342/150/ jaclaz

Yes, it happened before, expecially if the paper slip is thick and or screws were tightened too much, see here: Read ATTENTIVELY point #10 of the read--me-first: Guess WHY it was written that way? In a nutshell it says: See if anything here helps: http://buffalo.nas-central.org/wiki/Use_a_Nokia_Serial_Cable_on_an_ARM9_Linkstation @rmg See this report: jaclaz

Go by steps. Open a command prompt. Run in it MOUNTVOL [ENTER] How does the output look? Now run MOUNTVOL | FIND ":\" [ENTER] How does the output look? Now run FOR /F "tokens=1 delims=:" %A in ('MOUNTVOL ^| FIND ":\"') DO ECHO x%Ax [ENTER] How does the output look? Now run FOR /F "tokens=1 delims=: " %A in ('MOUNTVOL ^| FIND ":\"') DO ECHO x%Ax [ENTER] please note how the above has a [sPACE] between "tokens=1 delims=: and the closing double quote: " How does the output look? jaclaz

If you are also in DIY/Electronics, I can give you a nice idea for one or more of those: http://www.ian.org/HD-Clock/ Yep, that's the problem. Common sense and experience (and ONLY that, i.e. NO evidence whatsoever to backup this statement ) tells me that it has nothing to do with actual hardware, and it is/was a software problem, still of UNKNOWN origin. I suspect that the rotated cluster was the "last step" of something else that caused *some* kind of corruption - probably in RAM or in the filesystem driver, and then the "rotation" of the cluster which in turn produced more filesystem corruption. (but again I have nothing to support this claim) Rest assured, DMDE is one of the best programs around, only since it is VERY good and has LOTS of options is not something that I would advice normally to an unexperienced user, I mean if simpler tools can get the result, why using a more "advanced" one. Anyway, happy that the problem is now solved and I guess I can count you as another happy bunny: http://www.msfn.org/board/index.php?showtopic=128727&st=10 (though we won't probably ever know WHAT originally caused the problem ) If you plan to use that disk under XP please note that it is still "old school aligned" (since it was evidently formatted form a "standard configured" Vista) and this may - in a limited number of peculiar partitioning schemes (NOT in the one you are currently using) to lose a partition, see here: http://www.boot-land.net/forums/index.php?showtopic=9897&hl= jaclaz

There is always the good ol' method: you start the defrag you go to sleep leaving the PC working next morning you see what it did (unless of course you like watching the little coloured squares or bars moving up and down and right and left ) Seriously, next candidate: http://www.quusoft.com/products/system-utility/quusoft-disk-defrag/ at 50 bucks/year , it must be the eigth wonder of the world, expecially if you don't need all the other <put here an adequate word> they bundle with it. This thingy (just a wrapper): http://www.blueorbsoft.com/scandefrag/index.html seems like hinting (actually plainly saying ) that effective defragmentation on Win9x/Me requires "exclusive" access or however you EITHER defrag OR work with the PC in most cases: http://www.blueorbsoft.com/scandefrag/Readme.html the whole idea of a "restrictive" mode should mean something. Another candidate (cannot say if it will actually run on 9x/Me - it seems like this info is not available): http://www.softpedia.com/get/System/Hard-Disk-Utils/Uniblue-DiskRescue.shtml Yet another one (free AND seemingly Win9x/Me compatible): http://www.glarysoft.com/products/utilities/disk-speedup/ jaclaz

jaclaz

Reference: http://www.robvanderwoude.com/ntset.php ALREADY given you, look for "Environment variable substitution has been enhanced" jaclaz

NOONE can "recommend" a Commercial product or supplier on the MSFN board, I had a quick look on http://shop.ebay.co.uk/ and there are several options if you use "Europe Union" as target. If you want "real UK based" there are fewer options, like: http://cgi.ebay.co.uk/Micro-USB-RS232-UART-TTL-/220691378063?pt=LH_DefaultDomain_3&hash=item33623b2f8f http://cgi.ebay.co.uk/MAX232-RS232-TTL-Converter-Adapter-Module-Board-/120637873074?pt=LH_DefaultDomain_3&hash=item1c1693dbb2 http://cgi.ebay.co.uk/USB-TTL-Converter-/220682258137?pt=UK_ToysGames_RadioControlled_JN&hash=item3361b006d9 http://cgi.ebay.co.uk/DFRobot-USB-TTL-Converter-CP210-/140460217627?pt=LH_DefaultDomain_3&hash=item20b414d51b http://cgi.ebay.co.uk/USB-TTL-Serial-Cable-/290488791420?pt=UK_Computing_CablesConnectors_RL&hash=item43a27b317c http://cgi.ebay.co.uk/USB-TTL-serial-Convertor-/310122268633?pt=UK_AudioElectronicsVideo_Video_TelevisionSetTopBoxes&hash=item4834ba47d9 What you want (and you may want to contact the seller beforehand to make sure) is a 3V TTL level adapter (and NOT a 5V one). Rules are easy, if the seller doesn't know what the heck are you asking about TTL levels, do not trust him and go elsewhere. Compare with points #6 and #10 of the read-me-first: jaclaz

Which translated means: 2K/XP and later have a built-in dynamic environment variable "Date", as well as "Time" and a few other ones: http://www.robvanderwoude.com/datetimentbasics.php http://www.robvanderwoude.com/ntset.php What worked in NT may still work on later OS, but there are added features that are more handy. And, in case you asked for it (which you did ), you are not really the first one needing to put a date in a filename : http://www.robvanderwoude.com/faq.php#DateDir jaclaz

Without ANY evidence to backup my statement , which you then should take as a mere friendly advice from someone that has probably seen more problems on PC's than you, ANYTHING that contains "NAV" (as in Norton Anti Virus") or "Sym" (as in Symantec) or "Norton" (as in Norton ) should be removed first thing. Usually they are: unneeded bloatware problem causing The second step - with the same limits as the above - is to remove ANYTHING connected to ROXIO. Though they may or may not be the culprits, after having removed them you will have a faster, more responsive system. jaclaz

With all due respect , the idea of reading possibly the greatest English writer of all times translated into German doesn't particularly interests me. Back to topic, it 's such a pleasure to deal with you on any topic , you do actual testing, you do actual reports, you do actually contribute to the community. jaclaz

Yep , that's the general idea. Results depend on how "sound" is the underlying NTFS, so cannot say what would happen in your case. DMDE usually can find (and you can save from it) single files, but it is normally a long and tiresome project, doing one-by-one. The general approach is recover (automatically) "everything", then discard whatever you are not interested in. "dd" is the traditional sector-by-sector or "forensic sound" disk imaging program. If you have a "sound" filesystem you can use shortcuts, but in the case of a corrupted filesystem it is vital to image "everything", (meaning each and every sector) even what is not indexed or accessible by the filesystem. A list of programs is given here: http://www.msfn.org/board/index.php?showtopic=100299 The one I normally use as it does what I usually need is dsfo/dsfi (part of the DSFOK package): http://members.ozemail.com.au/~nulifetv/freezip/freeware/ but there are a few windows ports of the original dd. It is possible to write a small batch that will copy only the actual non-zeroed sectors to a sparse image (a sparse file on a NTFS volume is a file that has a "target, nominal" size but that will occupy on disk only the actually non-zeroed sectors) but the imaging would take a looong time and the actual occupation on target depends on the actual amount of data in the original volume (and please take note hat in this case also deleted data "counts"). Only you can say how "filled" the original volume has ever been. If you have nothing to actually lose, simply run chkdsk /f and see what happens. An alternative could be if you are interested only to a small number of files, and you know which type they are to use a file based recovery approach, PHOTOREC is excellent at it, if the original volume was defragged properly you have near 100% probabilities of recovering everything: http://www.cgsecurity.org/wiki/PhotoRec If you are willing to fork from a few bucks (which you seem like not, otherwise you would have already shopped for a 640 or 750 Gb disk and imaged the drive properly), this Commercial app normally can recover most things from a NTFS system: File Scavenger http://www.quetek.com/prod02.htm but there are many other tools, bothfreeware and commercial that you can try. In italian there is a proverb "Avere la botte piena e la moglie ubriaca" that could translate roughly to "Having the wine cask full and the wife drunk", that seems like applying to your approach :whistling:. Summarized: you have a problem (or a supposed) one you come here for help/suggestions you are told that steps are 1.,2.,3. you do them you are then told that following steps are 4.,5. and 6. (safe) or 7.,8.,9. (probably working but with a percentage of risk) you go idle thinking about steps 10.,13. and 18. (since 4 to 6 cost money and 7 and 9 are risky, and you don't fancy 11., 12. and 14. to 17. my good friend Mr Spock would define the above illogical The "right" thing to do is to image the drive first and then run chkdsk /f on it. The second "right" thing to do is use scroungentfs and/or ntfswalker and/or dmde and/or photorec and/or any Commercial corresponding utility/tool and recover the files from the volume, and then run chkdsk /f on it. The third right thing to do is take some risks and go ahead and run chkdsk /f on it. Anything else, given the amount of limits (of disk space and money) you have though perfectly possible will resolve in eiher a lot of time spent with dubious results or in no results and no way back. But still, the only thing that you should have learned - which, judged from the fact you didn't already bought a 750 Gb drive - (and I will probably loose my voice shouting it shortening my fingers typing it), is that the BEST approach to data recovery is NOT needing to perform it, which you should read as BACKUP!, NOW! ALL your data! Murphy's Law is ALWAYS around trying to prove itself right once again, the fact that you have already bitten by it doesn't mean it won't happen again, and it may also happen very soon. jaclaz

Still, you should dd the partition and THEN try running chkdsk /F on it. Most probably the drive will be revived , but why taking the chance? (Or take the chance of NOT running it and risk not being able to recover the data, or do so in lots of time or with complex procedures?) Attempting a (possibly partial) recovery on a filesystem that can possibly be revived by a simple chkdsk /f seems to me like making one's life more tough than needed. Comeon, besides the fact that you should ALREADY have had a backup, with today's hardware prices, you should get a 640 or 750 Gb disk and make the copy, if you really care about the data. The usage of scroungentfs seems clear enough to me : http://thewalter.net/stef/software/scrounge/win_usage.html But in any case, assuming that scroungeNTFS will recover each and every file on the volume WHERE do you think to store the recovered data? Since NTFSwalker is a no go, try using dmde: http://softdm.com/ jaclaz

Maybe variable expansion in the FOR loop? http://www.robvanderwoude.com/variableexpansion.php Try: FOR /F "tokens=1,2,3 delims=/" %%M IN ('date /t') DO ( set LOG=RegSettings-BSPResults(%%N-%%M-%%O).log echo RegSettings Results: > "%LOGPATH%\%LOG%" echo. >> "%LOGPATH%\%LOG%" echo The logfile is "%LOGPATH%\%LOG%"&Pause ) And: SETLOCAL ENABLEDELAYEDEXPANSION FOR /F "tokens=1,2,3 delims=/" %%M IN ('date /t') DO ( set LOG=RegSettings-BSPResults(%%N-%%M-%%O).log echo RegSettings Results: > "!LOGPATH!\!LOG!" echo. >> "!LOGPATH!\!LOG!" echo The logfile is "!LOGPATH!\!LOG!"&Pause ) WHERE is LOGPATH defined? jaclaz

I would try first thing: NTFSWalker: http://dmitrybrant.com/ntfswalker and ScroungeNTFS: http://thewalter.net/stef/software/scrounge/ Before going to Commercial apps. jaclaz

Maybe something like Setres (multimonitor version): http://www.iansharpe.com/downloads.php and nircmd: http://www.nirsoft.net/utils/nircmd.html May give you control of those. Check the setdisplay and setprimarydisplay commands of nircmd, cannot say if it does what you need. Or displayfusion: http://www.displayfusion.com/ but unfortunately it seems like NOT being in the Free version: http://www.displayfusion.com/Compare/ Multimon also has a Free version: http://www.mediachance.com/free/multimon.htm but again I don't think it has the feature you need/would like to have. There are also the Commercial Ultramon and Actual Multiple Monitors, but maybe, if you are eligible, this might be "just right" : Displaychanger http://www.12noon.com/displaychanger.htm This may be a good resource for a DIY job: http://www.naughter.com/qres.html jaclaz

Right again , though not actually related to "clusters", the $MFTmirr is the first 4 record of the $MFT, i.e 4 x 1024= 4096, which casually is also the size of the cluster on your NTFS volume: http://www.ntfs.com/ntfs-system-files.htm Same here. The difference btween the $MFT and the $MFTmirr is probably not so casually in the last two bytes of the "16 shift", i.e. 56 04 vs. 01 00. Personally (and judgng from the other "last bytes" I can see) I would vote for 56 04. But what can have caused this is still a mistery. jaclaz

Yep , as you say. Point is that you should read in that file "FILE0" at addresses (relative): 0 1024 2048 3072 but you don't, whilst starting at 4096 everything seems fine again. BUT then, if it is not a "shift" WHY the $MFTmirr is also "rotated"? However, test to do is: Copy just the first 4096 bytes of the $MFT to a file. Make a backup copy of this file as-is. Modify the file by inserting 16 bytes at the end of the file, then cut first 16 bytes of the file and paste them over the 16 bytes appended. Check twice and thrice that the file begins with "FILE0" and ends with (in your case) 56 04 and is 4096 bytes in size Save the modified file, then copy and paste it's contents over the $MFT on disk. You may need to disconnect/reconnect the disk and/or re-boot. See if the filesystem "re-appears". IF everything is fine and you can get back your files, get them , I wouldn't risk to run CHKDSK on that volume unless you have (as you should have) a "dd like" or "forensic sound" image of it. Something else that you may want to do BEFORE is to save the whole $MFT "as is", "fix" the first 4096 bytes as above, then analyze it: analyzeMFT http://www.integriography.com/ jaclaz

Yep, that's correct. Physical drives ALWAYS start at offset 0 as they are the "outer" container. Logical drives starts werever the data in the MBR (part of the PhysicalDrive) say so, in your case you are accessing first logical drive, which has 2048 sectors (hidden) before it. There is no such thing as "physical" vs. "logical" clusters (they are ONLY "logical" ), a cluster is simply a "group of sectors" and it's size (or better the number of sectors each of them contains) is defined in the bootsector or PBR and depends on: SIZE of the logical drive FILESYSTEM used in it Now, back to work. Besides the 16 bytes shift, the $MFT and the $MFT Mirror appear like identical. Can you repeat what you did, but saving this time 5 sectors starting at the same addresses? I just want to make sure that the rest of the $MFTmirr is still the same. I have no idea HOW this shift may have happened, it seems like 16 bytes have been inserted "somewhere" (evidently before the $MFT), since the $MFTmirr is also shifted 16 bytes. You should check also the bootsector copy (last sector of partition, i.e. absolute sector 1023999999 + 2048= 1024002047 or 2048+1024000000-1=1024002047 and a few sectors after it, the same 5 will do. I mean, if the second partition works allright, and it starts at 1024015230, the "exceeding" 16 bytes of the bootsector copy should get as first 16 bytes of the first "unused" space between first and second partition, i.e. you should have first line of sector 1024002048 ending with the "Magic Bytes" 55AA. Once made sure of this, we need to find WHERE the 16 bytes have been inserted, and this may prove tougher than it might seem. If you are lucky, the bytes have been inserted *somehow* in the NTFS "complete" bootsector (first 16 sectors of the logical volume). Save as before those 16 sectors +1, 17 in total and post them, together with the three sets of 5 bootsectors detailed previously. jaclaz