jaclaz

Yes, definitely NOT a "solution", only a temporary workaround to verify what the issue is. Let's try being more explicit. The cdob's posted menu.lst contains: #2 sets the source for the floppy image to XP_Inst.gz #4 maps (in memory, i.e. "volatile") the floppy image to (fd1) #5 maps an area of memory to (fd0) #6 hooks the previous mappings #7 makes a dd copy of first sector of the (fd1) to the image mapped in memory #8 is the MOST RELEVANT part, it should effectively replace the string "= firadisk32" with the string "= firadisk64" in the file TXTSETUP.OEM on (fd1). For *whatever* reason, it seems like this did not work as expected, what I suggested was to modify the TXTSETUP.OEM before (thus making it "fixed" for 64 bit install) to verify that this was the case. The "right" way is to have instead (as the original cdob's files do ) a "standard for 32 bit install" TXTSETUP.OEM and modify it only temporarily for 64 bit install. What needs to be verified now is WHY exactly the posted menu.lst "as is" did not work as expected and modify it in such a way that it works on your machines (and conversely to "everyone's) also. jaclaz

Maybe you could add to your report the adverb "unexpectedly", or maybe even "surprisingly". jaclaz

Yep , the idea is that until one has the whole amount of data (hopefully) recovered or decides to give up , there should always be a "working" drive, a "clone" (or image) one ready to restore the first if needed and another "target" drive where to store the recovered data. Good , that will do nicely. jaclaz

The Free edition should allow you to create the lists alright. If you want to actually attempt the recovery "en masse" you will need to get a license either the Home or Express version, but also remember that you will need *enough* space on an accessible volume where to save the recovered files. jaclaz

You wouldn't like to have US$ 2 bills and shop at Best Buy, though http://conservativeread.com/police-called-man-arrested-cuffed-after-using-legal-2-00-dollar-bills-at-best-buy/ "original" news: http://articles.baltimoresun.com/2005-03-08/news/0503080089_1_bolesta-pole-baltimore-county And be careful with old bills you dig out in your garden, too: http://www.t-g.com/story/1843748.html Hey, we could make a poll about members that could use 7.5 million dollars, with choices like: Yes, right nowYes, right about nowYes, within the next two hoursYes, within tomorrowYes, within one week timeYes, in a foreseeable futureNo. (I don't understand English, sorry) jaclaz

On the left pane select $Root. Right click and choose "Recover files". In the "Recover" popup window click on "List" button. Save the filelist.txt (on another volume). Click "Cancel" to close the popup Window. Repeat with the "clone" and compare the two "filelist.txt" files, if they are the same, there is no need to re-image back. You can try to recover (one by one) a few files from one or the other disk and compare the result also. Double click (navigate) on the left pane until you see in the right pane a file that you wish to try recovering, right click on it and select "recover files", point to another volume path and click on the OK button. Inspect the file and see if it is "good". jaclaz

The folders with the "red X" means that they are "deleted" folders (the point here is that this deletion was seemingly done by the CHKDSK). The LBA 16373784 that you see in the lower panel is OK, it is the beginning of the $MFT, which as we have seen earlier is on cluster #3, and since a cluster is 8 sectors, so 16373760+3*8=16373784. You can try inspecting with DMDE the clone you made (again on this you will need to choose the NTFS that DMDE finds and that will be presented to you as the volume starting at 16373760, and see if doing the same "Virtual file system reconstruction" it finds more files/directories (it is likely that you will have a "same" number of fies/directories but with less of them with the red "x", but it's difficult to say). If it does, then your best choice is still that of restoring the original disk from the clone, apply to it the corrected MBR I posted and then either continue with DMDE (getting a license for it) or see what other Recovery utilities may find on it. jaclaz

How exactlty did you "open" the partition? NO, that's the "botched" new partition that Disk Manger made, the right one, as I tried to explain you before the beginning of the existing partition is 16373760. Sure, you need to tell it to do the virtual file reconstruction. The DMDE is already "a" recovery program, let's see what it sees, first, if you prefer i doubt that *any* recovery program (exception made - maybe - for some pricey Commercial ones) can see "more" files than DMDE. The point here is with much less data than you have I have a much better result, which as said can mean only that the disk was modified (i.e. the data on disk is not the same as the snippets you posted/sent) or that some other issue in the parts of the $MFT after the snippet you sent causes CHKDSK to ignore almost all the data. Let's see what happens with the virtual filesystem reconstruction, instead of reimaging back the whole image, you can reimage back only the $MFT and see if DMDE can rebuild a better fielsystem, before doing the whole reimage. jaclaz

Try manually changing the line: to: for the experiment. jaclaz

This is very strange. I can get more data than you with my (very partial) image. Are you sure you did the steps correctly? (or that you didn't modify the disk since you posted those sectors?) With only about 150 records in the $MFT I get: It would be very, very queer that an error in the $MFT past the part that you sent me is capable of deleting files already indexed in that first part. The only difference in the image I rebuilt with your data (apart the smaller number of entries in the $MFT) are: the traces of the "wrong" partition deleted (but this is irrelevant with the new MBR I posted) the presence of a correct $MFTmirr (but in theory you should have one nonetheless) the presence of a correct $BootMirr (but this is completely irrelevant)and yet it gives "better" results. Try re-stating exactly the steps you made, maybe you unwantingly did something different from the instructions? What happens if you now open the disk in DMDE and click on [All Found+Reconstruction]? Now, your next step should be to image back the copy to the original, are you confident that you can do it without messing with disks or drives? jaclaz

Post your TXTSETUP.OEM, that error comes if you provide a "wrong architecture driver": http://support.microsoft.com/kb/885349/en-us I am not understanding what you mean, please try to describe this issue in more detail, or using different words. Try opening disk manager (when the USB stick is connected) and post a screenshot of it. Try opening disk manager (after you disconnect the USB stick) and post a screenshot of it jaclaz

No, just the last one. CHKDSK without any parameter does very limited fixes (in theory it is "check only") but it also does a "limited" check, i.e. it may ignore some problems (and report a filesystem as "sound" even it it has actually some issues). The CHKDSK /F is both a "generic fix" and a more thorough check. The CHKDSK /R is the most complete check (and set of fixes) you can have (and actually implies the /F). In theory you could run only CHKDSK /R which already comprises the two previous ones, but in practice it is better to run it in the mentioned three stages because one can visually understand the "seriousness" of problems in a filesystem, a CHKDSK or CHKDSK /F takes on a "sound" filesystem a few seconds/minutes, and - from experience, you can call it anecdotal evidence alright - it seems like the /F alone is *somehow* more effective than the same /F implied in the /R, or however "prepares" the disk for a more effective /R repair later. In your case you already (very recently) run the CHKDSK and the CHKDSK /F, so you only have to run the CHKDSK /R (this time on the "right" volume ). jaclaz

No, don't worry Leave it running CHKDSK is a built-in Windows tool thar REPAIRS (does NOT damage) filesystems. The only issue is that you NEED to wait for it to finish (it may take some time, i.e. even hours on a largish volume, to run, but eventually it will finish) and your filesystem (the "E:" that you selected by mistake) will be in the same (or better) condition than it was before. jaclaz

No. Start DMDE. When you start it a popup windows will appear. On the left of it there are Physicaldrives listed. On the right there is a set of radio boxes with - by default - "Physical Devices" selected. Select "Disk Images" instead. A "browse" window will open, navigate to and choose file Rightsector0.bin and press OK. A new popup window "Partitions" will appear. Click on th "Close" button. Now, Tools->Copy sectors. The "Source" will be "Image:<somepath>\Rightsector0.bin", Start Sector 0, End Sector 0, Number of sectors 1. jaclaz

Rather easy. Download the attached file and unzip it *somewhere*. Copy the Rightsector0.bin to first sector of the "botched" disk. To do that: Start DMDE, tell it to load an image file and point it to Rightsector0.bin. Click on Close in the "Partitions" window that pops up. Tools->Copy Sectors. Leave the "Source" pane "as is". In the lower "Destination" pane choose device, select the "right" PhysicalDrive, (double check) and press OK. Close DMDE. Reboot. You should have a drive letter for the volume, let's say it gets drive letter E:\ (or change below drive letter accordingly). Open a command prompt. In it type: CHKDSK E:[ENTER] It will most probably tell you that there are errors in the filesystem that cannot be fixed because the /F parameter was not specified. type: CHKDSK E: /F[ENTER] it will most probably output a number of lines telling you it is fixing this or that. Once it has finished type: CHKDSK E: /R[ENTER] it will most probably output a number of lines telling you it is fixing this or that. Once it has finished (hopefully) all your data should be accessible. Post reporting if something different from the above happens. jaclaz RightSector0.zip

@JorgeA Counterfeiting goods is not (software) piracy, and (software) piracy is not theft. JFYI, a quick visual guide: jaclaz

Please do read attentively cdob's post: http://www.msfn.org/board/topic/137714-install-xp-from-a-ram-loaded-iso-image/?p=1061029 PARTICULARLY this part: If you have not modified txtsetup.oem as above, the firadisk driver that will be attempted to load will be the 32 bit version, which obviously cannot work for 64 bit. jaclaz

We are not disagreeing at all , I was not saying that FAT32 per se does not provide speed benefits, I merely stated that your report (anecdotal or otherwise) is the first one I ever saw about these benefits being "noticeable" (which - again - does not mean "measurable"). The "pure folly" was not connected to "FAT32" in itself was connected to the WHOLE "experimental install of Vista, and of a 64 bit version of it, and on FAT32 and on a production system". @dencorso I have no idea about hyberfil.sys , I personally find the whole idea of "hybernating" a "feature that has NO practical use" (at least on desktops). Personally I tend to switch on a computer and never switch it off unless there is a need for doing so (which means usually once every several weeks/months), but the common usage in *any* normal business use of a desktop is to switch it on, work on it for some 8 hours or so (actually about 4 hours of "work" once you subtract the watching of Youtube videos or p0rn , some twitting, some Skype, some needless instant messaging and a huge amount of irrelevant emails, both sent and received ) then switch it off AFAIK. jaclaz

Well, there is the usual risk of starting a FAT32 vs. NTFS flamewar , I never did benchmarks comparing them on newer OS's, but the noticeable difference should be on 2K and not that much on XP, or at least this was the case for (slowish) USB devices: http://www.msfn.org/board/topic/125116-fat16-vs-fat32-vs-ntfs-speed-on-usb-stick/ Traditionally the difference in speed is connected with filesize, cache, and fragmentation level, this article is still valid: http://technet.microsoft.com/en-us/library/cc938440.aspx you could turn off (but this is a "global" setting) Last access time: http://msdn.microsoft.com/en-us/library/ms940846(v=winembedded.5).aspx and as said try with Mb aligned partition (which might produce a slight improvement). Personally, you will need to pry NTFS out of my dead hand , if not for anything else (like sparse files and hard links/mountpoints ), for the speed of filesearching through the $MFT , but of course you are very welcome to use FAT32, though as in the source of the already linked to "method" to have Vista installed on a FAT32 filesystem: http://www.911cd.net/forums//index.php?&showtopic=14181&view=findpost&p=119093 it is not that bad, after all. Problems (as you may read between the lines or outside of them ), are - as I see it: that tutorial was made with Vista 32 bit (and NOT 64 bit) so even if that is tested and confirmed, may (or may not) appy to the 64 bit version a Vista install uses hardlinks, which are probably part of the issues in point #4.) of that tutorial you are basically using a 64 bit system in order to gain access to more RAM (or there are other reasons that I am no aware of?) BUT you won't be able to have hyberfil.sys and pagefile.sys bigger than 4 Gb (unless you place them on another volume, NTFS formatted) the final scope of that experiment was to produce a smallish (limited) Vista to be installed on USB flash 7 (seven) years have passed since, and there is no evidence that any later SP or KB/update has not introduced some further limitations and/or that a number of programs won't "like" to be on FAT32So - and I know you didn't ask for my opinion (but I will provide it nonetheless), if you do that as an experiment, it is a nice one, if you do that as a "solution" for increasing disk speed on a "production system" it is "pure folly" . jaclaz

Good. DMDE besides the PhysicalDrive # should show you also the device type, so you should be able to further confirm that you are using the "right" devices, WD20EARS and WD20EARX jaclaz

May I ask you what is the original reason why you would not have it on NTFS? The speed of that SCSI disk? Which SCSI is it? (I mean 1/2/3 or Ultra160/320) Which exact disk model is it? How (EXACTLY) it is currently partitioned? (I mean is it using the good ol' cylinder alignment or the newish Mb alignment)? It is possible that aligning it to Mb you gain something, but it would be the first time that someone ever reports a noticeable (which does not mean "measurable") overall difference on speed NTFS vs. FAT32 on a relatively fastish bus. jaclaz

Sure , still around (and going strong ). Ideally you should have on the XP machine an added drive letter corresponding to the volume that you created by partitioning and formatting on the 7 machine, and if you right click on this drive letter, and select properties, you should see something similar to the screenshot posted here: http://www.msfn.org/board/topic/170392-how-to-recover-accidentaly-deleted-partitionfiles/?p=1061281 If you have as "Free Space" more than around 2 Tb, more exactly more than 2,000,398,934,016 bytes, you are good to go. To make an image: Open DMDE. Choose the "botched" PhysicalDrive (as you did before). Go to Tools-Copy Sectors In the top pane "Source" (make sure you have the "right" Physicaldrive in it selected) push the min button besides "Start Sector", push the max button besides the "End Sector". In the lower pane "Destination" click on File button, navigate to the drive letter corresponding to the newish/largish disk drive letter and click on Save. You will now see in the "Destination" pane the path to the image that will be created. Once everything has been checked, press "OK". If you cannot see the "new" drive on that XP machine, yes, you will need to re-partition the new drive as MBR (not as GPT) from within XP, then create a new partition/volume larger than 2Tb, formatted as NTFS. (no need for "third party utilities", though ) Which make/model is the "new" hard disk? (and which size is it)? Or you could decide to make a "clone" instead of an image. (a clone will be an EXACT copy of the source device, so it doesn't matter if and how the target device is partitioned/formattted as anything related to it will be overwritten by the data coming from the source device). To make a clone: Open DMDE. Choose the "botched" PhysicalDrive (as you did before). Go to Tools-Copy Sectors In the top pane "Source" (make sure you have the "right" Physicaldrive in it selected) push the min button besides "Start Sector", push the max button besides the "End Sector". In the lower pane "Destination" click on Device button, choose the PhysicalDrive corresponding to the "new" disk drive and press OK. You will now see in the "Destination" pane the path to the PhysicalDrive and the offset pre-set ot 0 (leave it as is). Once everything has been checked, press "OK". jaclaz

Good, and now read this paper (and understand the perils that cooperative mining may lead to IF a large group adopts selfish mining techniques): http://mashable.com/2013/11/04/bitcoin-cornell-researchers/ http://www.scribd.com/doc/181412760/Bitcoin-Mining-Vulnerability-Paper jaclaz

@frogman Maybe you are looking at it from the "wrong" side. I mean, leave alone the pins in the SATA power connector (i.e. what supposedly comes out from it), look at the wires actually clamped to it (i.e. what comes from the PSU and goes into the connector). If there are two blacks, one red and one yellow (and not an orange), it is perfectly OK that those three pins are missing, as seen in the Wikipedia article CharlotteTheHarlot posted. Each wire connects to three pins, if you have 4 cables 12 pins are OK. If you had 15 pins, 3 would be connected to "nothing". Most PSU's I have ever seen use SATA connector with 4 wires (i.e. without also the Orange/3.3v wire/line) as the 3.3V line is *never* used, I would say that it is the "opposite" of what Charlotte stated, in th esense that "old" PSU's, made when the SATA standard was newish do have the 5 wires and 15 pin whilst more recent ones - as soon as the PSU manufacturers understood that no hard disk diver manufacturer would use the 3.3V from the PSU - have 4 wires (and either a connector with all the 15 pins or with just 12 of them). The only device that I know of that are actually 3.3V powered are 1.8" SSD's, which have a microSATA connector and that are unlikely to be mounted in a desktop, and that would require an adapter *like*: http://www.microsatacables.com/1-8-inch-micro-sata-ssd-hdd-to-sata-adapter-with-bracket/ or: http://www.microsatacables.com/1-8-micro-sata-ssd-hdd-to-sata-adapter/ BTW you can anyway, instead of using this: http://www.ics-iq.com/product-p/pcar-6023-100a.htm use - for a mere 50 bucks more - use this instead: http://www.ics-iq.com/product-p/f.gr-0033-000a.htm jaclaz

This is something I asked myself quite a bit of time ago (and completely failed to understand), JFYI: http://reboot.pro/topic/15305-ok-lets-see-if-some-one-can-help-me-understand-bitcoins/ In my old-school simplicity when (and if) I will be able to walk to a bank (or pawn shop or postal office), give them a handful of bytes on some media and get in exchange 1,200 US$ (possibly in the form of 12 Benjamins ) then a bitcoin will have a value of 1,200 bucks. Besides, try googling for "bitcoin theft" jaclaz