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

Just for the record, there is more than one way to skin a cat (the cat won't like any of them, though ): http://alternativeto.net/software/agent-ransack/ For NO apparent reason : jaclaz

Possible. You should upgrade to some recent hardware jaclaz

Risking to go WAY Off Topic anyone has attempted a DIR of the WINSXS folder in a Windows 8 install or WAIK PE 4.0? I would say that the side by side mechanism - IMHO in itself a good idea, only very badly implemented - has been vastly abused. .Net is obviously nonsense bloat (still IMHO), being often in itself as big as or larger than a "normal" WHOLE Win 9x install. jaclaz

Not really. There is nothing like a $MFT backup, there is a $MFT mirror, which actually holds just first four records of the $MFT. What you report makes little sense (the manually disconnection of the cable(s) being related), if the disk was encrypted, unecrypting it in case of corruption should not have been possible, which means that there was a corruption of the filesystem while it was mounted (and the corruption itself was encrypted by Bestcrypt). The TESTDISK log shows how the $MFT is corrupted. The MBR and PBR seem apparently fine (though the MBR code looks like corrupted, but it has no relevance if not for booting. BUT, the MBR has LBA start 2048 and Num Sectors 117960704, i.e. 2048+117960704=117962752 total sectors, the PBR has 2048+117960703(+1)=117962752, while the image taken with datarescuedd has 60390005760/512=117949230 sectors. The image *somehow* misses seemingly 117962752-117949230=13522 sectors This seems like indirectly confirmed by the TESTDISK log (though it provides another difference): 60398080512-60390005760=8074752, -8074752/512=15771 Try opening the K:\image[0-60390005760].dd with dmde: http://softdm.com/ it may be able to parse the corrupted $MFT and allow at least the recovery of some files. jaclaz

Yep, the begin offset is 63 allright but those data do not make much sense. They are not the actual data related to a file, those correspond to entry #531 in the $MFT, possibly the $MFT entry for that file, according to the data till now gathered. In the "upper right" pane right click on the file name, you will have a set of choices, right now you seem like having chosen "Open MFT file (hex Editor)", while you want to choose the bolded "Open (Hex Editor)". Can you see in the lower right pane the beginning of the file? If yes, you will also see the LBA, vol.sec, Cluster and sec. of the actual file. Is this file recoverable? Save them somewhere for the moment. The strange thing is that you seemingly have valid data in both the MBR and the PBR, the $MFT is apparently there allright, as seen by dmde, but the filesystem driver fails to mount the volume (both through Imdisk and VDK). I am confused. Try another thing before anything else (on the "my500GB.img"). Open it with DMDE, does it show a window titled "Partitions - dmde 2.4.4"? Can you see two entries in it, the first one being: Image:<path>\my500GB.img etc. and the second: <label> Primary (A) NTFS (07) 500 GB EBCF 63 <some number> ? If yes, if you select the second the "Open Volume" button should become enabled, press it. A new popup should appear, titled "Open NTFS volume" with some data (post this data). Then press "Open" button. This way DMDE is using the data coming from the MBR and PBR (and not the results of the NTFS search). In the lower right pane you should see (first line): LBA:6291519 vol.sec 6291456 Clus:786432 sec.0 (MFT 0) If you open again the image, and this time you choose instead "NTFS Search" (start it and wait until "NTFS 0" appears, then press "start/stop") and then select the "NTFS0" and click on the "Open volume" you should get the same: If this is what happens, I am wondering what prevents the NTFS mounting with both IMDISK and VDK. jaclaz

Sure, imagine that you need to buy a Photoshop CS6 License in order to be licensed to use a "MS Paint like" lousy program on your lousy tablet. (or try to do some serious photoediting with your fingers instead of a pen). "Not that bad" is relative. And what if a company has a new, revolutionary, (BTW moronic) approach of only using Surfaces and "The Cloud" (which is actually what the good MS guys are pushing for)? They don't even have the hardware to actually install one of the senselessly bloated "complete" Office suites, in order to be allowed to run the RT version on their tablets. Additionally (and only slightly OT) using "seriously" Excel without direct access to Fn keys and without a Numeric Keypad is a lot like doing Muay Thai with both your hands tied behind your back and your legs tied together and to to the pavement... jaclaz

Start from here: read a few posts. And/or see this: jaclaz

Then (if it results as accessible on the othe PC), clean thoroughfully the USB related entries in the Registry on your PC and try again, see: and links therein jaclaz

No, this has nothing to do with the bricking or the unbricking, those are related to the device being inaccessible, now you have access to the device (and to one of the structures on it) but not to another structure (partition/volume/filesystem) on it. This could be caused by a "simple" corruption of the filesystem (or one of the identifiers/indexes) or a physical corruption of some sectors on the device. Start a new thread, now you are not anymore in the 7200.11 unbricking, but in "generic" data recovery. jaclaz