jaclaz

Good, now you should be able to put (copy and paste or, better import) the contents of the .log into a spreadsheet. In theory you have a "good" or almost good 134 Gb image, so anything (roughly, you will have to make the math exactly) before: 134 GB=~134*1024*1024*1024=143881404416/512=LBA 2766950084 should be already on your image, so in the spreadsheet you order by LBA address and get the chunks that are missing. Now there is the usual doubt about which strategy to use to get the missing data. Basically there are two theories - no way to know which one may give you "better" results, depending on the actual issue one or the oher may work better, or both could work the same, or both could fail: theory of "little by little" <- you just try to get the chunk that you need theory of "greater area" <- you try to get an area of the orignal disk larger than the chunk(s) you need, and then you re-parse this to get the exact chunks Theory #1 is based on the hypothesis that the head going to a given place is more exact" than "passing by", theory #2 is based ont the opposite hypothesys. Of course on a disk that has no issues both would work perfectly, but you never know, additionally datarescuedd has also an option to get sectors in "reverse reading", which sometimes helps. The BAD news are that seemingly, and though fragmented, that particular file seems like being entirely within he first 134 Gb . Which could mean that your image already contains some corruprted sector Try getting all single chunks from the original disk with datarescueDD. Once you have extracted (hopefully) all 12 "chunks", you can re-assemble them by using COPY +, but it is usually more convenient using some od the tools in DSFOK toolkit: http://members.ozemail.com.au/~nulifetv/freezip/freeware/ If you sum the sizes of the chunks in the spreadsheet you get 1072 sectors, i.e. 1072*512=548864 which should also be the size of the file that you see in Explorer or in DIR... So you do: This will create an empty file of that size in bytes. Then you use: dsfi C:\mytemp.dat <offset> 0 <filechunk.dd> which means copy to C:\mytemp.dat, starting from offset <offset> for all it's length (0) the <filechunk.dd> where offset is the offset in BYTEs of the filechunk and the <fileschunk> is the name of the file extracted with datarescuedd, the first chunk with your data should be image[2030112256-2030120448].dd (where obviously 2030112256 is made by the LBA offset*512=3965063*512=2030112256 and 2030120448 is the offset+the length, i.e. 3965063*512+16*512=2030120448) The use of a spreadsheet is advised as it will produce the exact command lines faster and without the risk of typing errors. jaclaz

Good. Try using the attached batch. The output of myfragmenter is expressed in Logical Cluster Number (relative to the Volume) and Virtual Cluster numbers (relative to the file). The batch converts (or attempts to ) those in "plain" "absolute" (i.e. relative to the disk) LBA addreses and Sectors lengths of the chunks or extents. The settings: are already set in the batch for the disk values you have. jaclaz myfragi.zip

Which program/tool (and under which OS) are you using it to write on the disc? How EXACTLY are you using it? If you are using "multisessions" or by any chance the disc become "finalized", you will have NO available space on it, no matter how much data is on it, but since it is an RW, you can make a copy of the files on it, re-initialize the disc and copy back the old and new files anyway. jaclaz

Why should you be (or anyone else for that matters) be wrong, you are reporting your opinion, based on your experience. I guess everyone is happy for your satisfying experience . This doesn't in any way negates how colore's experience was seemingly dreadful , nor my personal opinion that in most cases using a 64 bit OS gives not any practical advantage, or if you prefer is/was UNneeded and - in times of Windows XP - it was actually very rare to find suitable hardware and thus a PITA. My crystal ball - though foggy - tells me that soon someone will post something like: and some other of the usual 64 bit fanboyism, so - as a preventive measure - I will post a couple links: http://reboot.pro/17568/ http://reboot.pro/16544/page__st__25#entry151030 jaclaz

@tomasz86 Last time I checked pagefile.sys was a system file, cannot really remember on NT or 2K. http://ss64.com/nt/attrib.html I presume that you would need anyway to turn the System state to off before being able to hide it (and reset it to System in the "same go"), but the file should be in use anyway and thus possibly allow you not to change it's status.... jaclaz

http://www.nirsoft.net/utils/bulk_file_changer.html That CRAP looks a LOT like Adobe XMP (and you thought that Windows 8 was the bottom of the barrel, didn't you? ) http://metadatadeluxe.pbworks.com/w/page/20792219/Adobe%20XMP There is in theory a field for the specific app that wrote the metadata, but obviously the good MS guys dumbified it by writing UNconditionally "http://ns.microsoft.com/photo/1.0/"'>http://ns.microsoft.com/photo/1.0/" and "MicrosoftPhoto" http://www.exiv2.org/tags-xmp-MicrosoftPhoto.html BTW, see here: http://metadatadeluxe.pbworks.com/w/page/20792236/ExifTool%20import%20function,%20jpeg try accessing: http://www.iptc.org/std/Iptc4xmpCore/1.0/xmlns/ or: http://purl.org/dc/elements/1.1/ and the corresponding: http://ns.microsoft.com/photo/1.0/ It's the senseless "PhotoGallery" since Vista http://blogs.msdn.com/b/pix/archive/2006/08/16/702780.aspx http://blogs.msdn.com/b/pix/archive/2006/08/23/715340.aspx and probably the "enhanced" search too. jaclaz

Nor does the XP one, one can use DOS and WINNT.EXE, the "original" way to install XP from USB (by running WINNT.EXE) is several years old, and actually starts from internal hard disk: http://www.911cd.net/forums//index.php?showtopic=16713 as well there have never been issues in making a WINNT.~BT and WINNT.~LS on another hard disk and transfer them to the machine (still through DOS), but here it is not even clear if the actual Cd-ROM dive is functional.... jaclaz

I would have thought that the migration tool was designed for that: http://technet.microsoft.com/en-us/library/cc722032(v=ws.10).aspx though I have NO idea about it's compatibility with the (IMHO) senseless 64 bit OS's, apparently at least up to Vista they are supported: http://technet.microsoft.com/en-us/library/cc721840(v=ws.10).aspx jaclaz

Hmmm. Try it on a file on another volume (a "good" one, with a working filesystem). For very small files it won't work as they are stored directly in the $MFT, but it should otherwise work (I don't think that there are issues with the "sparse" nature of the underlying file, as it is mounted in IMDISK, you could try using a different mounting tool/driver, but it shouldn't actually matter). Try another tool. Get myfragmenter: http://www.mydefrag.com/SeeAlso-MyFragmenter.html (part of mydefrag): http://www.mydefrag.com/Manual-DownloadAndInstall.html make SURE to use it with the -i switch, i.e. myfragmenter.exe -i F:\my_path\my_file.ext What happens? Also please, when posting the result of a command, post also the EXACT way you invoked it (command line), you did not specify how you invoked GetFileExtents, it could be that you invoked it wrongly (in the sense of having given it a non existing path or whatever)... jaclaz

No, you need to provide the full path to the target file. If you want to know the extents of file (say) F:\my_path\my_file.ext, you would normally run: GetFileExtents.exe F:\my_path\my_file.ext hence: gfe.cmd F:\my_path\my_file.ext or gfedec.cmd F:\my_path\my_file.ext jaclaz

I have the avantage on you , I actually know how there are more than one, how they are named and where to find them . BCDL: http://bootcd.narod.ru/bcdl150z.zip http://www.paraglidernc.com/temp/bcdw201a.rar SmartBootManager: http://sourceforge.net/projects/btmgr/ PLoP: http://www.plop.at/ grub4dos: http://reboot.pro/forum/66/ http://code.google.com/p/grub4dos-chenall/ The old 0.4.2 version: http://sourceforge.net/projects/grub4dos/files/GRUB4DOS/grub4dos%200.4.2/ does contain a pre-made floppy image Though there is still an issue: jaclaz

Mr. Ford selling his model T without steering wheel in order to have third party steering wheel makers rich? As a matter of fact somthing like this happened , but not because there was NOT a perfectly working steering wheel supplied with the car, but because some users were too fat to get into the car: http://www.modeltford.com/item/3503TW.aspx The dumbified version of Windows interface will undoubtedly make a market for undumbifiers, but you are seemingly missing the point about the actual differences between Windows 8 (and it's "normal" underlying working, exception made for the N.C.I.) and the Windows RT that has a completely different "codebase" underneath (while it has the same N.C.I. on top). jaclaz

Remember me to file this under "News" jaclaz

Yep : You may want to redirect the output of running getfileextents to a file, so that you have a list of the offsets (it would be a good idea to later use a spreadsheet to make a list of them. A simple batch may be of use (make a directory C:\GFE\ and save this as GFE.CMD : @ECHO OFF SETLOCAL ENABLEDELAYEDEXPANSION Set File=%~dpnx1 ECHO FOffset: LBA: Sectors: File FOR /F "tokens=3,5,7 delims=: " %%A IN ('getFileExtents.exe "%File%"') DO ( CALL :octify Foffset %%A CALL :octify LBA %%B CALL :octify Sectors %%C ECHO !Foffset! !LBA! !Sectors! %File% ECHO !Foffset! !LBA! !Sectors! %File%>>gfelog.log ) ECHO.>>gfelog.log GOTO :EOF :octify SET %1=0000000%2 SET %1=!%1:~-8,8! GOTO :EOF depending on the spreadsheet and local settings you use, you can replace the spaces in the line: ECHO !Foffset! !LBA! !Sectors! %File%>>gfelog.log with either [TAB] or [COMMA] or [sEMICOLON] jaclaz Edit: Typo in the batch. "Good" version attached (just in case) Edit2: Added as attachment gfedec.zip, that directly outputs decimal data instead of Hex gfe.zip gfedec.zip

Yes. Run it at first without parameters, then - again - with /F parameter and then - again - with the /R parameter. Let's see what happens. jaclaz

You see, in the log there is: Now we do know (from the PBR/bootsector) that the $MFT mirror is on cluster 61048000, i.e. 61048000*4096=250052608000 (given or taken the few sectors before) i.e. around 250 Gb, i.e. well beyond your "good" 134 Gb, so in practice thre is NO $MFT mirror. Actually - on a "normal" image it should be there (in the worst case) as all 00's BUT you have a sparse 500Gb image, so the $MFT Mirror actually doesn't exist at all. (I hope I make some sense to you now, a sector in a sparse file does not exist until something actually performs an operation on that sector). This may be connected (or may be not) with the Windows IFS driver incapable to recognize the NTFS volume (error you have in IMDISK) and with the TESTDISK log (though it may be only PART of the issue). The idea is to first thing use TESTDISK to create a new $MFTMirror from the actual $MFT, see here: http://www.cgsecurity.org/wiki/Advanced_NTFS_Boot_and_MFT_Repair before attempting running CHKDSK. jaclaz

Did they not clean the mess of the dead corpses after having KILLED the poor, little GOD's creatures? You may want to ADDITIONALLY clean the monitor from the inside jaclaz

But you can still open it in DMDE , this time being NOT propmpted with: and see the $MFT contents with it? Since (the good thing is) that the image is a "copy", we can play a bit with it. What happens if you mount it in IMDISK , open a command prompt and run in it: CHKDSK F: (provided that the drive letter assigned by IMDISK is F:, of course)? But BEFORE that, can you check it again in TESTDISK, and do three things: do a log of the session check/verify/fix the $MFT Mirror post the actual log jaclaz

Chances are pretty much low (if none at all) . But I wouldn't be (yet) so pessimist. The good thing (it depends on a number of factors) of having an encryption through a "mountable volume" could be that the volume (container) is created in a whole chunk (i.e. it is not fragmented). If this is the case (and unless there is a logical/physical defect in the actual SSD, such as an internal corrupted table of remapped sectors of wear leveling mechanism), it should be possible to recover the RAW data (PHOTOREC or similar file-based recovery). A single 55 Gb sized file/volume is however biggish (and thus increases the chances of some sectors having being corrupted for *any* reason). I would anyway try another attempt at it, you never know. Yes, more generally, encrypting *anything* is in "normal" use, not only of no actual practical advantage, but as you have unfortunately experimented directly, a big obstacle to anything related to recovery if an issue arises. In Italy we have a saying "mettere il dito sulla piaga" which equates to "to touch a sore point" (only somehow more crude/descriptive) and believe me, I am sorry for the loss of your data, but I have to : http://reboot.pro/9297/#entry80938 On the other hand the good outcome of this misadventure of yours could be that you have learned (the hard way) something about the futility of encryption in general and of large encryption containers more specifically. If you look at it in another way, you have forked from a noticeable amount of bucks to buy a SSD drive for what? Speed, good, pure, raw speed . And what is your next step? Adding a layer of computing power need/slowness through encryption..... I doubt about the professionaliism , but you are welcome. jaclaz

But, as already mentioned a Smart Car would run a Smart GOOD, REAL TIME OS, such as QNX: http://www.qnx.com/ For a comparison between a Porsche 911 GT3, a Toyota Hi-Lux and a wheel-barrow see here: http://www.911cd.net/forums//index.php?showtopic=24502&st=12 jaclaz

Dell has seemingly based the book on an assumption. The assumption being that the target for Windows 8 are users already capable of reading, which seems not like the case, as everything as already said is seemingly targeted to 5 years old. Every time an "additional" instructiion manual comes for something that is supposed to be "easy", "intuitive", "self-explicative" I tend to believe that either the instruction manual or the thing supposed to be easy are a failure. About Apple, I had a few of them, even today if you run an old System 7 or 7.1 (1993 or 1994) you can see how it was years ahead of the comparable Dos/Windows 3.x and even much better than Windows 95. Believe me when I tell you that it is another world (a word I have no actual use for , but still another world ). My mom - now over 80 - got her first computer about two months ago, and she learned to operate an iPad decently (for what her needs are: e-mail, web browsing, a couple dictionaries/encyclopedias, Skype) in less than two weeks and with very little intervention/assistance by me or friends (and without needing toread an iPad for dummies guide). jaclaz

HOW can this have happened? You posted: re-do, this time make sure that the resulting sparse image is actually 500105281536 or slightly more than that. jaclaz

This is the whole point. The total sectors in the structure is hence the filesystem expects to have: (976768002+1+63)=976768066*512=500105249792 but the image you reported making is LARGER than that (so the volume should "fit" ): Can you check (right click in explorer and select properties or do a DIR in a command window) the EXACT size of the image ? Possibly (and for *any* reason) it is actually smaller than the previously stated. jaclaz

Yes. I do not want 16 sectors (because I already know how in the best cases there is only one meaningful sector in the first 16 sectors - the MBR - which I already have), I want to have a look at the first 100 sectors because they will contain sector 63 and the following 16 sectors (up to 95) that may be non-zero. If when the disk was originally partitioned the new Vista and later "partitioning paradigm" has taken place, I will need instead first 2100 sectors. If you prefer by providing 16 sectors instead of the asked for 100 you didn't fulfill my request at a 16% rate, but rather at a 0% rate (or at the most at a 1% one) and I need it anyway fulfilled at 100% (or possibly even at 2100% ) The reference to the normal location of the $MFT it was because you talked of having scanned first 5 Gb, the (bad ) news were that normally the $MFT is at around 3 Gb, so it should have been found (if it is still there). jaclaz

Yes, hdhacker gets at the most 16 sectors, you need to use dsfo or a dd of some kind to get the 100 sectors. A "normal" NTFS volume has it's $MFT starting at cluster 786432, i.e. at 786432*4096=3,221,225,472 or around 3 Gb give or take a few sectors (sectors before) on the first partition. Of the sectors you posted, only the first is non-zero (this is normal) and it does contain a MBR code but NO MBR data (all 4 partition entries are 00's or wiped"), it is identical (obviously) to the one you already posted. This is most uncommon , as it seems like NOT the result of a "random" corruption, but rather of an "intentional" wiping of just the partition table . Additionally you have two bytes at 0X1BC that are normally 0000 (unused) set instead to A025, but this could be *something* related to XP64 or a "flag" placed there for *any* reason by almost *anything*. Were you - by any chance and at *any* step - prompted to "initialize" the disk (in disk management or explorer)? (a just "initialized" disk does have the "right" MBR code but NO MBR partition data) jaclaz