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

Well, decisions violating the First Amendment (or similar Freedom of press or speech) are IMHO a tadbit tough to apply to people not making money (integrally or partially) through merely re-distributing pre-made content (by others). The real issue here is about "wideness" (or "selectivity") of the blocking ("by address" vs. "by content"): http://www.reuters.com/article/2013/11/29/france-streaming-idUSL5N0JE2G920131129 Which nicely brings us back to the known Megaupload case. I have personally no particular sympathy for people that makes money through violating intellectual property rights, so, if these people ONLY did that, I am perfectly fine with that court decision, the point is whether the approach will lead to block websites where this activity is only marginal and when exactly we can call it "marginal". I have (hypothesys) a site with 100 pages. 99 are my own intellectual property or self generated content or however PD or similar. 1 is something "pirated" that I share publicly. Till now the holder of the intellectual property would send me a cease and desist letter and possibly, making leverage on the Millenium Act make google remove the result of a search. The complete opposite case: 1 page is my intellectual property, 99 are "pirated" content. The court decision seems to say that since (the specific domains) are entirely or almost entirely dedicated to they must be blocked. What if the pages are 50/50? And when they are 20/80? jaclaz

logman query providers ?? http://ss64.com/nt/logman.html http://technet.microsoft.com/en-us/library/cc788030.aspx jaclaz

@Charlotte You cannot take out some info from an unrelìable source such as Neowin and then start babbling about a few "Civil Servants". Read the source article: http://torrentfreak.com/u-s-caught-pirating-military-software-pays-50-million-to-settle-131127/ The DoJ has confirmed the settlement but won't comment it. http://www.dallasnews.com/business/business-headlines/20131124-irving-software-firm-settles-suit-with-u.s.-army-for-50-million.ece Essentially the good US G.I.men agreed to pay for a given amount of licenses and then used 18 times (like in 9,000 vs. 500) the amount for which they paid. It's not a single "civil servant" (or a bunch of them) that can deploy that number of installs and/or authorize their use in critical missions. And someone (not a "civil servant") must have authorized the signing of the settlement and consequent expenditures, US$ 50 millions are not "peanuts", were not they convinced of the wrongdoing, they could well have gone to Court. This said, I wonder who (in his/her right mind) would pay US $ 5,000 for single device license for something that sounds a lot like a "ral time tracking" software, let aloneUS $ 1.35 million per license of a software on a single server, I mean how much are the software costs of (say) UPS or DHL? jaclaz

Then, most probably cp works "correctly" with sparse files, this is good. The big issue (just verified with the sectors you sent) is that the actual part I was looking for, the "Root directory" is failed/blank. The Root starts on sector 63+32+238409+238409=476913 The bunch of sectors you sent are blank from 476913 to 476977, where a .pdf file seemingly begins. This is confirmed by the ddrescue log: 0x0E8DE000=244178944->244178944/512=476912 <- here 512 bytes (1 sector is missing, but most likely it was empty being the "tail" of the 2nd FAT) 0x0E8DE200=244179456->244179456/512=476913 <- here there are errors extending for 7168 bytes, and these are VITAL 0x0E8DFE00=244186624->244186624/512=476927 <- here 512 bytes (1 sector is missing, but most likely it was empty being the "tail" of the Root Dir) 0x0E8E0000=244187136->244187136/512=476928 roughly 15 mb (0x00ECE000=15523840) from here are "good" :thumbsup: As said there are more "holes" in the log, of course besides the above, the other one that would be very, very useful is this one: Which corresponds to sector 95 The second copy of it should be on sector 238504*512=0x7475000, which is also a "hole": The other "holes" (which would anyway be better if removed) hopefully belong to single files or to sectors that would have been anyway empty. jaclaz

Good. I got the files and will try and see if I can get out of them some better "fake" sector 95. In the meantime, you could see what happens running again ddrescue (with the log file, using the same destination file, see the docs): http://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html#Introduction maybe using in addition the "reverse" switch and without the "n" one. The log you posted has seemingly some "issues", there are quite a few "holes" or "gaps" in it. By retrying with different parameters it may help in "bettering" the image, recovering some more sectors. I am also perplexed about the "type" of the image (and of the copy of the image) you made. I mean the effect of the "S" parameter is to have a sort of "sparse" file: and this -generally speaking - while saving the space occupied by the image, makes it "non-copy", i.e. the copy will be expanded. How big (in bytes) is the "clean_disk_image.bin"? (filesize and size on disk) And is the copy you made of it the SAME size? jaclaz

I had seriously mis-read/mis-understood the issue. If the problem is "cannot login to Windows XP", possibly one of the simpler approaches is logging in without password (and then create a new "normal" account), and hopefully a simple way is to use a USB stick with PassPass (yeah, it's a "plug"" ): http://www.msfn.org/board/topic/163190-passpass-bypass-the-password/ http://www.sherlock.reboot.pro/passpass-bypass-the-password/ jaclaz

I was thinking more at this one : jaclaz

the NON-written part: .... it merely fixes the stupidity of previous update 2670838, any normal person would have made a new update, replacing the old, flaky one and including this fix, or at least put a link to KB2834140 on the actual KB2670838, but we are MS and know better.... jaclaz

267038 or 2670838? http://support.microsoft.com/kb/2670838/en-us The list of non compatible laptops is impressive. But maybe it is just a matter of installing a suitable video driver? jaclaz