jaclaz

In which "form" are the Shadow Copies generated with that command? I mean is the end result a .vhd or .vhdx image file, right? There are several tools that can access them, I suspect that the issues with Shadow Explorer are more with some conflict/file in use/permission/UAC/whatever than with actual filesystem/image access. jaclaz

WHICH clicking? You didn't said anything about clicking. (or I missed it ) (is it not by any chance something like 11 or 12 clicks, then a pause, etc.?) WHAT "detects it as unknown device which is not initialized"? When the disk is connected "normally" to a SATA port (and powered) what do you see in the BIOS? What happenas if you simply connect the power (and not the SATA bus) cable to it and then switch on the PSU from which you get the power? Does it spin, does it click with a "pattern"? (please describe). jaclaz

It is entirely possible that given the "huge" size of the disk CHKDSK from XP failed for you (but it worked alright for me with the very "partial" - please read as much smaller $MFT - image I rebuilt) and that Windows 7's CHKDSK is "better" for this scope. That would be a nice explanation on why it worked "here" and did not "there". The issue with partitioning is, as it is explained in the thread I provided a link to (and that evidently you completely failed to read ): http://reboot.pro/topic/9897-vistawin7-versus-xp-partitioning-issue/ essentially the following. ALL MS Operating Systems up to and including XP/2003 adopted a convention that said that each and every partition and/or volume MUST start on a head boundary and end on a cylinder boundary.. In the case of the most common 255/63 geometry that equates to EACH partition and volume starting on m/a/1 and ending on x/254/63 (as seen in a MBR or EPBR, where cylinders and heads are numbered starting from 0 and sectors are numbered starting from 1), where a can is usually 0 or 1. As an example, the first (primary) partition on any disk partitioned on any OS up to XP/Server 2003 would begin on 0/1/1 (first cylinder, second head, first sector) and thus at LBA 63 (and the hidden sectors, including the MBR are 63), since the partition will always end on x/254/63 (i.e. on last head, last sector of a cylinder), any subsequent partition (including the Extended one, if not the first) would begin on m/0/1 i.e. on the mth+1 cylinder, first head, first sector). Any volume inside extended will also respect this head boundary, i.e. given that an extended partition starts at m/0/1, the first volume in it will start at m/1/1, i.e. there are always 63 "hidden" sectors (including the EPBR). If you prefer, and this is evident in Disk Manager or better in one of the "orthodox" partitioning tool that have a "slider" to choose the size of a partition, the slider movement is not "fluid", but goes in steps which are around 8 Mb, more exactly 1*255*63*512=8,225,280 bytes. Vista broke this "tradition" or "convention" and aligns by default to a Megabyte. A typical first Primary partition created under Vista or later will begin at 0/32/33 or LBA 2048 (consider how 32*63+33=2049 and how 2048*512=1,048,576, il.e. exactly 1 Mb). Any subsequent partition will also use this alignment i.e. each partition or volume start will be a multiple of 2048 sectors (or of 1 Mb). In your case, as I tried telling you on post #11: http://www.msfn.org/board/topic/170392-how-to-recover-accidentaly-deleted-partitionfiles/#entry1061133 16373760 is divisible by 2048 = 7995 i.e. is "Mb aligned". The "bug" is in the XP Disk Manager that not only does not "understand" properly this "new" convention, but - in the case of logical volumes only - tries to "fix" these data it finds "wrong" creating the havoc you just came out of, i.e. deleting the correct partition data in the MBR, creating a new EPBR on the nearest cylinder/head boundary and additionally creating a bootsector for the volume in the "wrong place". Now, aligning a partition/volume to the Mb (as opposed to cylinder/head) is said to provide some better access/transfer time. This is mostly nonsense, in the sense that on a high speed bus (such as SATA) and with decently fastish disks (and with largish caches) this advantage is not noticeable and actually - when measured - pertaining only to some of the typical usage of the disk (again do READ the given thread). With the advent of larger and larger disks (and with the most common OS becoming increasingly a Vista or post-Vista OS) hard disk manufacturers have started to optimize the disk firmware for "Mb aligned partitions" (which BTW only apply to NTFS filesystem and not to any FAT16/32), so that possibly (but I am unaware of any "serious" benchmark in this respect ) having a "Mb aligned" partition/volume does provide some advantage, though in the case of a disk dedicated to data only and mounted ot a NAS (and thus accessed mainly if not exclusively through the much slower LAN/Ethernet) such theoretical improvement in speed will be in practice totally vanified by the slow speed of the network. The bug in the XP Disk Manager, as said ONLY affects logical volumes inside Extended and/or Extended partitions and DOES NOT affect Primary partitions/volumes. So, your choice is between forgetting what the good WD guys say and do not align the partitions and keep using an Extended partition and logical volumes in it (which would be silly, since you have no *need* whatever to use Extended partition and logical volumes as you can have as much as 4 primaries, and have them aligned to "Mb") or align the partitions/volumes to the Mb BUT be limited to have a maximum of 4 volumes (four primary partitions) on the disk. Of the two, the second allows to be compliant to the suggestion the WD guys make (no matter if *needed* or *useful*) while being sure that the XP Disk Manager won't by mistake mess with the volumes. jaclaz

Well the "known" issue that seemingly bit you was due to THREE concurring things: a volume Mb aligned a volume inside Extended use of XP Disk ManagerAs long as you take any of the three out of the equation, everything should be fine and dandy. As said personally I would go for "cylinder aligned" (no matter if primary partition or volume inside extended) because that is the convention used by the MS guys (and by anyone else) until Vista came out, but a volume Mb aligned BUT primary AND use of XP Disk Manager is as well fine. Partitioning/formatting under XP and then using other tools to re-align partition to Mb has already failed for you (cannot say if it was your original choice/decision to have the second partition a volume inside extended or if the software induced you to make it in such a way). jaclaz

Interesting. You seemingly found another nice can full of worms awaiting to be opened. Summing up the info here: http://superuser.com/questions/472524/is-there-a-way-to-use-volume-shadow-copy-on-windows-8 and here: http://blogs.msdn.com/b/b8/archive/2012/07/10/protecting-user-files-with-file-history.aspx a lot of questions arise. The contents of the FAQ - if I read them correctly - are appalling , it seems like you can have not a "real" Shadow copy made, but only one for a limited numbers of folders/locations. The question is, see also this: http://blog.cwl.cc/2012/03/windows-8-file-history-is-new-new.html even if it is possible to re-implement *somehow* the "Previous Versions" tab, can we also "widen" the "target", i.e. have the stupid Windows 8 make a shadow copy also of something that is not inside the given limited paths? jaclaz P.S.: It seems that quite a bit of tinkering is needed to have Shadow Copy actually working on 8 but at least it is possible (still not connected to the missing tab in File properties): http://blog.quiscalusmexicanus.org/2013/01/21/some-notes-on-reinstating-shadow-copies-on-windows-8/

I am missing something. You should have now TWO "sources" one (the original disk) on which CHKDSK was attempted to run - but failed) and one which is a clone of the original disk NOT being affected by the CHKDSK run. Assuming that you recovered on the third hard disk ALL the files you were interested in, your next step would be to (virtually) go back to the same as before the issue, i.e. with the "original disk" containing a partition (this time either Primary or NOT aligned to Mb - if XP will be used on that disk) with all the files in it. No matter how well a filesystem can be reconstructed or fixed, and particularly when it is only a "data" disk, it makes little sense to run a "repaired filesystem" (provided that DMDE can actually "fully" repair it). I mean, if I were you I would: (optionally) wipe the "original" disk with a single 00 pass (and it will take time) create a new (this time either primary or cylinder aligned) partition/volume on it (you can use the MBR I posted, which has a second partition Mb aligned BUT Primary in it's partition table or recreate just one partition still Mb aligned and Primary under 7) copy the files/directories from the "third" disk to this volume (optionally) and only once you have triple checked no more files can be (or you want to) recover are needed on the "clone", wipe it also with a single 00 pass (and it will also take time) Finally re-format (under Windows 7, without the "quick" or /Q switch) the partition on the "third" disk that hosted temporarily the recovered filesI tend personally to never suggest the wiping of a disk unless needed, but in cases such as this it represents the best choice IMHO. The "risk" with NOT wiping the disk before recreating the partitions/volumes would be "marginal" in the sense that should in the future another "hiccup" such as the one that just happened on that disk, data recovery might be more complex because artifacts of the "previous" filesystem and of the rebuilt/repaired one may "confuse" the software. Same goes for the disk that currently is the "clone", I presume you want to put it back into "service", and starting from a freshly 00ed disk gives more probabilities in the unlucky event that something goes wrong with it in the future that data recovery will be possible, and same goes for the new "third" disk that I presume you will also put into service. As a side note (sorry but I have to say this), if you actually implemented a suitable backup policy before you wouldn't have had any need to perform the data recovery, and maybe this could be used as a "lesson": always have a backup (better if two) of any meaningful data. jaclaz

Good. A much better question BUT we have an issue here Dependency Walker can detect what DLL's (or other "connected" file) functions a given .exe is "connected" to (statically), but in order to "truly" know what the program "wants/needs" you need to "profile" the app (i.e. run it from within Dependency Walker) in order to see what is used dynamically. To be of some use this needs to be done on both the "tested" OS/install (i.e. one in which the tool/program works fine) and on the "target" OS/install, because besides the mere existence of a .dll (or of a given function inside it) there are several other possible issues that may prevent the app/program to actually run in the "target" OS/install. The extensive use of Dependency Walker in (example) making a BartPE plug-in (or a Winbuilder .script) or more simply have a given tool/app working on a very reduced system, either manually made or - say - nlited (and the actual "base" OS is the same) is already a nightmare (and far form being "easy" or "fully reliable") I would say that using it to establish when running it under - say - XP whether a given program is compatible with a much different OS (like 9x/Me) seems to me like a "lost cause". If instead the idea is to use it as a sort of "sieve" to quickly determine if a given app is NOT compatible with win 9x/Me (because it invokes a .dll or a function inside it that is not present in those OS, then it may have IMHO some merits. Maybe in better words, analyzing a file with one of these tools may give you proof (or a quick way to learn ) that something is "NOT compatible", but won't ever be "enough" to tell you that it will run under the "other" OS (which supposedly is the "final goal"). To list the imported .dll's (and functions) in a given PE file, you can probably want to try using besides the mentioned ones a tool like CFF Explorer Suite: http://www.ntcore.com/exsuite.php and - for dynamically loaded modules - the nice, little Dynlogger: http://www.ntcore.com/dynlogger.php This thingy here: http://www.silurian.com/inspect/index.htm is also a nice tool IMHO. jaclaz

What? Care to explain expand on this? jaclaz

The only device where a touch interface would be welcome (at least by the boys) . jaclaz

"Run it in Windows 9x physically", no, wait, that is "aside", then "Run it in Windows 9x virtually" Seriously, now . It makes little sense IMHO to know if something is "compatible" with Windows 9x, any given program may be "compatible" with Windows 9x but not running in it (for a zillion possible reasons), just as an example an app may be "compatible" with 9x/Me, but only run in - say - Windows 98 SE or in Windows 95 but not in Windows98. Can you explain what your goal/ise of such a method would be? jaclaz

Sorry for the delay, for whatever reason the board did not notify me (or I missed it) about your reply. The files you sent are OK (though you made just extension of 1 sectors for all of them). It is very possible that you cannot get that last sector because of a miscalculation on my side or simply because it is "outside reach" of the Hdhacker . With the data you posted the "right" sector is 573939712 (for the fifth file). However there is nothing "wrong" with those sectors if not - as TESTDISK reported the geometry in the bootsector of the seond partition, but that would only create issues if you were booting from it (while you are actually booting from the first one). What happens when you choose the partition and press P in TESTDISK? jaclaz

No, nothing connected to 8.3, all your errors - as expected - are with "reparsepoints" which you can read as "hard or soft links or mountpoints", Try - as Dietmar did - to create just the empty directory/directory structure for each one of those. You can use a small batch/oneliner to re-parse the output log you have. Something like: FOR /F "tokens=2,3 delims=:" %%A IN ('type mylog.log ^| FIND "\"') DO ECHO "%%A:%%B"If it works (or modify to make it work, I did not test it), replace ECHO with MD. I would personally also experiment with XXcopy. NO prob . jaclaz

@Trip At the time ycopy was developed exactly to allow that kind of "blind copy" and go on notwithstanding the errors (but logging them ): http://www.ruahine.com/download.html http://www.ruahine.com/faq.html http://www.ruahine.com/guide.html Really cannot say if it works on newer Windows and/or if it is suitable to the experiment, though . jaclaz

Why don't you ask for support to the Author of that Warez release (whoever he/she is) then? On this board support to WAREZ is NOT provided, please READ (attentively) the Etiquette/Rules: http://www.msfn.org/board/index.php?app=forums&module=extras&section=boardrules particularly Rule #1.a jaclaz

Difficult to say, it could be the actual adapter DOA or more simply a cold solder (or improper connection of the wires you are using). You can try directly connecting the two Tx/Rx pins with - say - a pair of tweezers or little pliers to exclude the wires and use a multimeter to check continuity on the actual board. If the issue is/was the actual PCB, there would be no need to communicate to the disk through hyperterminal and the TTL adapter, the disk should work "as is". Be aware that there are reports in some "normal" cases of (successful) debricking - for unknown reasons - the MBR partition table and/or some other "key" sectors on disk were corrupted or however made invalid and that some partition/filesystem recovery was needed in addition, example: http://www.msfn.org/board/topic/145574-seagate-750gb-one-partition-is-raw-after-bsy-fix/ What I would personally do with a (hopefully) unbricked disk would be to connect it to an already booted PC through a USB (or e-Sata) connection, i.e. "hot-plug" it, as there are also reports of such unbricked disks that when connected directly to the motherboard prevent the PC from booting. jaclaz

For NO apparent reason : http://www.imdb.com/title/tt0084967/quotes?item=qt0378851 @JodyThornton I will issue this official statement : To the best of my knowledge, the only successful attempt to install Vista on a FAT32 partition was the one Dietmar made in 2006 (and a link to the method he used was given). I listed what - in my experience and opinion - could be the additional issues that you may face in either attempting to replicate that method adapting it to the 64 bit (newer, i.e. with SP's) version of the Vista OS or using a different method, as a way to try and help you. Still as far as I know, noone ever attempted (let alone succeeded at) installing a Vista x64 on a FAT32 partition, so the matter is IMHO very experimental if not "first time ever", hence it is unlikely that you will be able to find a MSFN member (or anyone else ) capable of answering to questions like: from direct experience, and I believe that what dencorso meant when he suggested you to start carrying your own experiments was intended as a similar advice. 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