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

Well, AFAIK not even Windows 98 has been updated recently.... Maybe you can try using a launcher with process priority features, like this one (examples): Myrun http://ex-boroda.chat.ru/english.html ATM http://www.simtel.net/product/view/id/12339 Cannot say if it can work.... jaclaz

Possibly yes , but the point you seem like missing is HOW the NTLDR/BOOT.INI way of booting Windows 9x works. In order to boot Win9x NTLDR chainloads a COPY of your partition bootsector (the "original" one installed by Win9x to the PBR and invoking IO.SYS). If needed bootpart can RE-CREATE that bootsector copy. The XP Repair AFAICR, won't. In a nutshell, how your 9x boots: After Win9x install: BIOS->PBR (of Win9x)->IO.SYS After 2K install: BIOS->PBR (of Win2K)->NTLDR (of Win2K)->BOOT.INI (of Win2K, with 2 entries, 1 for Win9x)->bootsect.dos->IO.SYS After XP install: BIOS->PBR (of WinXP)->NTLDR (of WinXP)->BOOT.INI (of WinXP, with 3 entries, 1 for Win9x)->bootsect.dos->IO.SYS What the repair fixboot would do would simply to re-write the PBR (and possibly check that in BOOT.INI there is an entry for the XP install). This is perfectly equivalent to running bootpart WINXP BOOT: C: , this will allow to boot in XP.(and you don't need the XP CD or to boot from CD) The difference is that if, for any reason, the bootsect.dos is invalid, or has been deleted, you won't be able to boot Win9x. With bootpart you can also, once booted in XP or 2K, recreate the bootsect.dos copy of the Win9x PBR. jaclaz

VERY nice. Some details about the uncompressed BOOTMGR and if a given version is needed may be of help so that other people can experiment with your findings..... Just for the record, your post is on sanbarrow's "new" board http://forum.sanbarrow.com/index.php but previous posts/topics are on the "old" board here : http://sanbarrow.com/phpBB2/index.php jaclaz

It depends on HOW you access the disk. If you access the \\.\PhysicalDrive: the MBR is at LBA 0 (first sector) the PBR is at LBA 2048 the MFT should be at 786432x8+2048=6293504 If you access the LogicalDrive or Volume: the MBR is NOT available the PBR or bootsector is at LBA 0 (first sector) the MFT should be at 786432x8=6291456 It's years I don't use WinHex, and I am not familiar with it, but if it uses absolute byte addressing: 0C000000=201326592 201326592/512=393216 So it is NOT: Now, be nice. Get Tinyhexer. Open the \\.\PhysicalDrive: File->Disk->Open Drive You will get to sector 0 or MBR. Now: File->Disk->Goto Sector/Position 6293504 Select the sector. Edit->Copy. Edit->Paste to new Save the file, zip it and attach it to your next post. Do the same for sector 63999999x8+2048=512002040 (which according to the PBR is your $MFTmirr) If you access the Logicaldrive you DO NOT have the 2048 sectors before, thus addresses are: 786432x8=6291456 and 63999999x8=511999992 jaclaz

Yep, but you really should read the second thread, which is about a situation VERY similar to yours, and does contains some info that may be of use to you. The actual $MFT, according to your PBR/bootscetor is on cluster 786432 (normal for a NTFS volume). You have 8 sectors clusters (again normal) From BOTH your MBR and PBR the partition starts at LBA 2048. 786432x8+2048=6293504 <- This is where your $MFT should actually begin. Can you check it? jaclaz

...which corrupted the MBR. It's a binary file, you cannot copy and paste or save from a text editor! Read the file with hdhacker. Save the fie with hdhacker (naming it like "MBRdisk0.bin") DO NOT OPEN it with notepad ir ANY other text editor, actually DO NOT open it. Compress MBRdisk0.bin to MBRdisk0.zip. Attach MBRdisk0.zip. jaclaz

With all due respect for the opinions of the members who posted , this seems not a poll like: or Multibooter, for reasons that should not be up to debate, wants to defragment under Windows 98, his question seems like clear enough to me. ...and I thought mine was not an answer .... I guess Multibooter is old and experienced enough a member to know what he is asking for and he most probably has a reason to ask this (and not another question).... jaclaz

Well, NO. IF "drive E:" is hidden, it doesn't get a drive letter, hence it is NOT "drive E:" (maybe it is "third partition" ) You may want to try using showdrive.exe or mountstorePE, reference here: http://www.boot-land.net/forums/index.php?showtopic=10169&hl= Of course NOT, batch files are only written in order to make sure that keyboard keys are not stuck, that's why a lot if % and &'s are used in them. Sure , a well written batch does work (as well as anything well written in any scripting or programming language), you can shoot yourself in the foot in several ways : http://www.kirchwitz.de/~amk/shoot_foot.shtml You'd better start a new thread about the batch here: http://www.msfn.org/board/forum/66-programming-c-delphi-vbvbs-cmdbatch-etc/ jaclaz

The disk having been formatted by Vista originally may cause a misalignment (of whole sectors and not of the 16 bytes) that can lead to problems if used under XP. The initial part was "FORGET (temporarily) the MFT"! Hdhacker is straightforward. You want to select first sector of the PhysicalDrive (\\.\PhysicalDrive0 is first disk, \\.\PhysicalDrive1 second, etc.) and press "Read sector from disk", then press "Save sector to File" and save it - this is the MBR. Repeat with first sector of the Logicaldrive - this is the PBR or bootsector. Then get ANY compression utility compatible with the ZIP format and use it, 7-zip is advised, but virtually anything can do. http://en.wikipedia.org/wiki/7-Zip http://www.its.ipfw.edu/training/howto/7_Zip_EncryptionProcess.pdf The compression is needed for two reasons (in this case NOT to save a few bytes, it is likely that the resulting archive will be bigger than original data): .zip is an extension that is allowed for attachment on the board if there is any corruption in the upload or download, the archive won't verify Yep but it's not a secret: http://www.boot-land.net/forums/index.php?showtopic=8734 (had you actually READ the threads I pointed you to, you would ALREADY know that) I guess I am allowed to express some perplexities on your tastes when it comes to excitement? What about this, then: http://web.archive.org/web/20080331030514/http://www.somethingawful.com/fakesa/fetish/ jaclaz