jaclaz

Yes (meaning No ) you are wrong. There is nothing particularly "bad" in a file being fragmented (actually it is quite normal that a file, expecially a "growing one" becomes fragmented over time or - more simply - the deletion of files creates "empty spots" here and there that are later filled by a single larger file that then becomes fragmented. On a healthy filesystem this is "normal" and there are no issues whatsoever because the exact position (and sequence) of clusters where the file is stored are recorded in the FAT table(s). The issue here is that the FAT tables of that stick - for whatever reason - have been overwritten/are invalid. The "patch" I sent you is made of an adequate bootsector and of two empty FAT tables assembled together with the (valid) ROOT directory already existing on the stick. This allows for "normal" listing of the files/dirs, but the DMDE (or any other program) has only the info to where the files starts - and since the FAT tables are empty it assumes that the file is contiguous, i.e. it "virtually maps" enough clusters to contain the file size starting from it's starting address. If you prefer, all filesystems after some use do become "scrambled eggs", but you normally have a slow motion video of the scrambling that you can virtualy play backwards to make again the eggs "as they were". No. Sorry but you have not yet grasped the above illustrated concept, the cluster map that DMDE provides is a "virtual one" or, if you prefer it represents the FAT tables how they should have been if ... The idea is not bad, only (and simply) it doesn't work like that. Imagine that you have a toy shop. A mad employee opens (say) 100 boxes of (different) puzzles and puts the contents all together in a bag. Your mission, should you accept it is to re-compose all puzzles in order to put back all the right pieces of the puzzles in the right box, then put together the pieces of the single puzzle you are interested in. And you don't know if the mad employee (being mad) did not hide, destroy or paint "white" a certain number of pieces, both of the puzzle you want to rebuild and/or of the other puzzles. So, you have two questions that only have very vague answers: Can it be done? Yes or no, it depends. How long will it take? Cannot say, it greatly depends on the original contents of the file and of the contents of all the other files, to continue in the puzzles example if the one you want to put together depicts a wiinter panorama oof a city and all the other 99 represent beaches, sea views, reproductions of still life paintings, etc. it will be easier, if all 100 represent winter panoramas, it woud be really tough. The puzzles examples are good because they introduce the concept of "art", data recovery is as I see it a (very marginal ) form of "art", let's say painting, in due time you can learn allright the techniques used in it, but if you are not an artist, the resuts will not be good to the eye. More seriously when it comes to manual recovery, it is "artisan work", you need experience and (deep) knowledge of the matter but you also grow your own "style" and abilities, when it comes to it, it is perfectly possible that one expert can make nothing of it (or take "forever" in doing it) while another one may put together "the pieces" quickly and successfully, there is simply no way to know in advance. jaclaz

Yes, and No, those are deleted files, these cannot normally be recovered or - as a matter of fact - only the "last written of them" may. if you watch accurately on the right, you will see how most of them "share" the same cluster beginning address. Yes, I understand this, the file is (was) evidently fragmented. There is rarely a definite answer when we are talking of data recovery, maybe yes/maybe no. Yes and no, it depends by such a big number of factors that it is really difficult whether one of the (Commercial) specialised tools might be able to do some magic. In DMDE, if you check the entry for “Yahoo v Impulse System.xls” you will see how it begins (maybe) on cluster 371 (filesize 8909312 243.09.2012 16:36), BUT if you scroll down a bit, you will see that you have an entry for a (deleted) “Yahoo v Impulse System.xls~RF1c4f8a1.TMP” that begins on cluster 331 (filesize 8909312 243.09.2012 16:36). Since we have clusters sized 32,768 bytes, a file 8909312/32768=271,89.. will occupy 272 clusters and thus it is evident a "superimposing". If you go: Tools->Update Custer maps Tools->Cluster Map then you start "navigating" the "bottom window", (with cursor keys) you will see how clusters from 331 to 370 are not allocated, (and thus may contain the "beginning" of the excel file), if you continue (right cursor arrow) up to vcn 271 and go beyond it over vcn 272, you see that the filename changes, BUT if you go "backwards" (left cursor arrow) you will notice how the "same" area is now linked to "other files". It depends on how much you value those data. Without any actual guarantee of recovering the whole file (or even anything more than "bits and pieces") we are talking of hundreds of US$, since there are some (I presume) earlier versions of that file - and depending on the actual contents of the file - in some case is possible to "combine" data or as said earlier extract values and re-use formulas from an older copy. jaclaz

Not really. In the sense that it didn't solve the problem, it removed the whole problem but also the "special" HP MBR CODE and any "recovery" partition, I thought that the general idea was to salvage those before proceeding. For future reference, if you want to exit the loop in which you got entangled (AND lose all partitions/data ) it's enough to wipe the MBR (first 512 bytes of the disk) or, in most cases, zero out just the Magic Bytes "0xAA55" (bytes at absolute offset 510 and 511 or last two bytes of first sector) with *any* disk editor or -from linux - with dd. jaclaz

From the colour of it it seems like coffee made by the nutrimatic: The first question that come to mind is: how big must become Redmond to host the whole MS complaints department? or - maybe more suited - : how many new jobs will it create in India and east countries? jaclaz

I have some good news . The thingy was originally formatted as FAT16 (not as FAT32) with a cluster size of 64 sectors/32 Kb. What actually happened remains a mistery, both copies of the FAT tables are lost forever, but I managed to re-build a bootsector (with *valid* data) and two empty FATs that are enough to let DMDE (or TESTDISK) see the WHOLE root directory (and hopefully link to the contents of the subdirectory). Still you won't be able to recover undamaged any file that was fragmented, and further recovery (in any case a partial one) can be possible only operating manually (a longish and "dirty" - in the sense of frustrating - job). Instructions: you have an image of the stick "as is" in C:\dsfok\usb_full.img make a COPY of it as c:\dsfok\usb_full_fixed.img unzip the attached to c:\dsfok\ (C:\dsfok\usb_500_patch.img) open a command prompt and in it do: dsfi c:\dsfok\usb_full_fixed.img 0 0 C:\dsfok\usb_500_patch.img use DMDE to access the image c:\dsfok\usb_full_fixed.img alternatively you can use TESTDISK When using testdisk: Open a command prompt and navigate to the directory where you have testdisk, actual executable should be testdisk_win.exe, issue: testdisk_win.exe /log c:\dsfok\usb_full_fixed.img then (in the testdisk UI): Proceed None Advanced Boot List (then use "c" to attempt copying files) OR: Proceed None Analyse Quick Search P (then use "c" to attempt copying files) jaclaz usb_500_patch.zip

Got it. I'll have a look. Sorry, misunderstanding, the "stats" you already posted are useful to examine the usb_10000.img (larger snippet) they were/are unuseful with just the usb_100.img (smaller snippet). jaclaz

NO. (meaning that if you used \\.\physicaldrive1 then you got it (maybe). I mean if the stick is still functional, the idea of making an image is that you use the image (of copies of it) and leave the stick alone. But i'ts Ok as well in this case, since you don't have issues mounting/accessing the device. Since you do have an image (the C:\dsfok\USB_full.img), you could have used it as source for dsfo instead of the actual stick/physicaldrive. The stick sounds a lot like being bought in 2005 or 2006: in 2001 a 2 Gb stick probably didn't actually exist (or it was at a "crazy price" ), a common sizes in 2003 were 128/256/512 Mb, a 1 Gb sick was "huge", see history of Netac for year 2001: http://www.netac.com/Netac-Histroy.aspx or date first available here: http://www.amazon.com/Kingston-Traveler-Flash-DTI-1GB/dp/B000AV14M2 You did nothing "wrong" , the stupid stick *somehow* had an issue, you are perfectly innocent, sometime it is just the actual stick "inside" /controller or flash memory), sometimes a "quirk" in the mounting/unmounting/writing to it of the OS, sometime is not using the "Safely remove" tray icon or however not properly flushing the write cache.... jaclaz P.S.: Try Zshare: http://www2.zshare.ma/

Lots of them , rest assured. For the record "the system" does not normally change a fixed disk from "basic" to "dynamic", it may prompt you to do so, and you actually need to click on Yes. The issues here are several ones, by using every possible way to fiddle with the disk it is possible that you have already brought it "beyond" possible recovery, mind you. From what you write, it seems like the original HP MBR (the one that you missed backing up BEFORE starting the procedure ) is still there (since - if I get ti right - you can still press F11 to get to the HP recovery partition). This is good. Now, what have you got available/handy that you can actually boot the PC to? (Like Linux live-CD, PE on USB stick, etc.) (I need a copy of the MBR "as is" to have a look at it's contents and - hopefully - suggest you a course of action) Or have you got an "expendable" ( in the sense that you can backup data now on it) USB stick that you can use for this? jaclaz

Well, then most of what I have seen in my crystal ball was wroong after all. Seriously, I was making the hypothesis that you had a "fake" USB stick, i.e. one bought as being (you choose) either 4, 8, 16, 32 or 64 Gb BUT being actually a 2 Gb stick "tricked" into showing as a bigger capacity device. If you bought that stick as being a 2 Gb one and it is actually a 2 Gb one (dsfo produced a 1817706496 bytes file, which could be more or less "right") the reason of the filesystem corruption may lie "somewhere else". Yes, once I get the "larger" snippet, the "DMDE stat" data you posted might be useful. Do you remember if you used that stick "as is" (or re-formatted it with the standard XP/whatever "standard" format command) or if you ever ran on it such tools as "HP USB disk utility" or any similar software that creates a MBR and partition table on it? Now, how you could have gotten the 51200 bytes? if you use the same approach writing 5120000 instead of 51200 (and calling the resulting file C:\USB_10000.img) what would be the result? Besides posting the above file (if I will need a bigger one I will tell you), can you try running ChipGenius on the stick and post results: http://reboot.pro/4661/ (just to understand what is "inside" the stick) jaclaz

Well, the good news are that seemingly DMDE managed to either find a "sound" or "almost sound" second copy of the FAT or more likely some "good" directory entries. Of course this does not means that *all* files will be recoverable (or that they will be recovered without further processing. Trying one file is not a "senceful" way to proceed, in the sense that you cannot get any conclusion from a single specimen, for all we know you might have been "unlucky" (please read as "very lucky" ) and that particular file may be the ONLY one damaged.... As a matter of fact, due to the hypothized "wrap around issue", the most "recent" files are those that are mre likely to be damaged. In this cases - besides the fact that some knowledge of the way filesystems (and "recovery tools") work - the approach is usually a "negative" one, once you have recovered all possible files, you do a map of the actual clusters used by them, then see if "the rest" do contain bits and pieces of the "still missing" ones and see if you can "re-assemble them" or at least get the data from them. That particular Excel file is particularly big, depending on the way it has been originally copied/saved to the stick, it is likely to be fragmented. It seemingly starts on a "early" cluster, that could mean that it have been saved there when it was smaller and later updated (growing in size and possibly "wrapping around"). There are tools (I don't think that Freeware ones exist, though) capable of (sometimes) recovering the contents from a damaged Excel (.xls format) files, they actually get the values (and not the formulas) and need anyway some manual work to "fill the gaps". However I see that the DMDE is on sector 16 which cannot possibly be an actual root directory, since it is identical to sector 0, these are evidently "parts" of the root written "in the wrong place" due to the issue. Let's do another thing (I still miss the info about the original capacity of the stick). If it was 8 Gb, extract from the image first 2*16000+2000=34000*512=17408000 bytes from the "whole" image, zip the result, upload to a free hosting site and PM me the link. You can do the math allright in case of other sizes. jaclaz

Look, I don't want to seem grumpier than usual, but EVERY SINGLE CD/DVD drive ever built does have a small hole for mechanical opening of the tray. If the motor/sledge of the tray is - for any reason - jammed, OBVIOUSLY *ANY* software won't be able to open it. ALL softwares send a command to the tray motor, basically telling it "Open Sesame" If Ali Baba had put a huge rock blocking the cave door, you can yell "Open Sesame" till the end of time, but until you remove the rock, it won't open. If when (through ANY software) an Eject command is sent, and you can hear the motor attempting to open the tray and the tray doesn't open is a mechanical issue that must be solved mechanically. It's not really rocket science: http://www.gotknowhow.com/articles/how-to-unjam-a-computer-dvd-cd-rom-drive http://www.ehow.com/how_2324439_eject-stuck-dvdcd-drive.html Some ZIP drives had it on the back, but I cannot recall a single CD/DVD drive NOT haviing it on the front: http://www.ehow.com/how_8398212_remove-stuck-floppy-zip-drive.html Yes, you may need to disassemble the drive from the case, if you cannot reach the small hole from the outside "as is". If you post some specs of your PC or a photo of it, it would be easier to give you some more specific instructions. jaclaz

Yep, those are the side effects of taking the RED pill.... Yes. No. Meaning that in order to provide (hopefully) any detailed instruction (or more likely pointing you to an already available resource suited for your needs), I need to understand what you are up to. And of course since last time I checked the Service Pack of XP was #3, I doubt that my crystall ball will be able to understand what you have in your SP4 .iso... Most probably you are after this : http://www.911cd.net/forums//index.php?showtopic=24880 but it's not an .iso (it is an .img - which gives a couple advantages) and it's not about SP3 or SP4 (BTW, there is no actual reason AFAIK/AFAICR for wanting a SP3 Recovery Console, in the sense that nothing has changed that has a relevance in recovery console). jaclaz

If you don't want it to also make some coffee , and you can use some temporary space (possibly as much as the original partiton occupied size) maybe a simple use of http://www.partition-saving.com/ to make an image in a number of suitable sized files and then "burn" these latter ones to CD/DVD would do. jaclaz

Yes, and the topic strangely enough, has already been discussed at length. The actual issue is "translating" an assigned drive letter to the actual disk/volume. Some "suitable" ways have been developed, see: page__st__20__p__821889?do=embed&embedDo=findComment%3Fcomment%3D821889' frameborder='0' data-embedContent> ooops, back to boot-land reboot.pro: http://reboot.pro/index.php?showtopic=8219 (of course only if a "third party tool" is acceptable, the thread(s) here by Victor888 contain more "native only" approaches/ideas ) Additionally (and if I remember correctly) the PE 3.x (please read as your Windows7 install environment) may be running a "enhanced" version of WMIC, so possibly that could be another path to follow. Also, you may get some ideas from this little .vbs: Assembling these ideas and testing them is of course up to you. But what you need seems to me like a very simplified subset. Boot to that .iso , open a command prompt and run in it: diskpart [ENTER] list disk [ENTER] list volume [ENTER] select disk 0 list partitions [ENTER] select disk 1 list partitions [ENTER] What do you get as output at each command? jaclaz

Guess why exactly your "title" is "Newbie" whilst mine is "The Finder" Sure we can talk of it . jaclaz

I think you missed my hint. You asked a base question on another forum in the grub4dos section. You got a (valid) reply. BUT since you slipped on a chocolate-covered banana : http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/put-down-the-chocolate-covered-banana.html You changed the question. And you got another (valid) reply to that new question (that in the meantime has become having nothing to do with grub4dos) Instead of continuing there you decided to bring the topic here, WITHOUT citing the original thread where a (valid) solution has already been given, i.e. omitting the relevant info that you already have, and starting again "from scratch". As I see it, your current question is (or should be): This way also someone that knows nothing about grub4dos, diskpart or Unattended install of a 7 from a .iso may help in assembling the script and someone else that knows nothing of grub4dos or scripting but is familiar wth Unattended installs of 7 may contribute, as well as experts of diskpart only... In other words the more info you provide as backup/background of a question, the more likely it is that people will be able to provide you with assisatance. jaclaz

@ragnargd I presume this originally inspired you: http://thpc.info/dualboot.html EasyBCD (which BTW by now is not anymore free) uses (senselessly) .Net, but much worse than that, uses grub4dos, "renaming" it as "neogrub" (and pointing to the help/references of GRUB legacy). There are several ways to make a triple boot 7/XP/9x system, the mentioned guide is suitable (though using unneededly and only in order to make it "easy" the EasyBCD tool) for a multi-partitioned single disk. Since you are using several devices (it is not clear to me whether you are using 2 or 3 SSD's, one is for 9x and there are other 2 for 7 and xp or just another one for xp/7 "together" ) there are simpler/better ways (and several different options). Only the triple booting alone would need a separate (longish) thread as well as having 9x running on a modern hardware (and with more than 1 Gb RAM) - as a matter of fact such of these long topics already exist. Very loosely the situation is the following, you have: an (oldish) OS that uses NOT a bootloader and NOT a bootmanager (9x) a OS (XP) that uses a bootloader that can double as (limited) bootmanager (NTLDR) a OS (7) that uses a bootloader that can double as (limited) bootmanager (BOOTMGR) optionally a (good) bootmanager that does not double as bootloader (grub4dos - or the "renamed" neogrub) optionally other sets of tools (MBR loaders, redirecting bootsectors and what not) There are more possible combinations of them than you can possibly want to know, out of all the possible ones you made your choice ("right" or "wrong" doesn't really matter ) which is OK (as long as it works for you) the point beiing simply that other people may want/need (and can have) a different approach that is more "suited" for them. jaclaz

Didn't you ALREADY get a possible solution to this? http://reboot.pro/17636/ jaclaz

So you get OEM PCs with Win7 until 2014. http://www.zdnet.com/how-to-skip-windows-8-and-continue-using-windows-7-7000001734/ Spot the differences : Fictional conversation (Phone call or e-mail exchange) #1 that will happen in - say - January 2013 (in the case Windows 8 sells not as good as expected): Fictional conversation (Phone call or e-mail exchange) #2 that will happen in - say - January 2013 (in the case Windows 8 sells very well): jaclaz

The code is right, the .iso is not, and - besides - you are in the wrong place. This is "Install Windows from USB", although some of the methods do use grub4dos, it is NOT titled "grub4dos" or "grub4dos support forum" or "since a few guys that use grub4dos hang around here feel free to ask any questions about grub4dos". You: FORGET about getting an XP recovery iso from the internet go here: http://reboot.pro/ Where you will find SEVERAL different threads/ways/methods to boot a XP recovery .iso from USB ("flat", as ".iso" and as ".img") after having MADE yourself the Recovery Console. This is one (that contains also several links to related threads): http://reboot.pro/5316/ BEFORE it, please read these two: http://reboot.pro/8944/ http://reboot.pro/5041/ jaclaz

Yep, so why don't you use a smaller disk image mapped to --mem (which will be loaded faster AND will live you more RAM free AND will give you no issues with EMM386)? This was the idea of the questions about "size" of the image.... You can have a second image mapped "normally". You can even try having the same image mapped another time (without --mem), in which case you can use copy or Xcopy from DOS to save to it Or you can try using a dd port to dos to image the drive mapped in --mem before rebooting. An oldish one should be here: http://www.ibiblio.org/pub/micro/pc-stuff/freedos/gnuish/ in gnufut21.zip: http://www.ibiblio.org/pub/micro/pc-stuff/freedos/gnuish/gnufut21.zip (there may be several other programs suitable) jaclaz

Actually the "original" code is "the right one". For *any* reason that BIOS does not detect "properly" the device Cylinder number. How big is the device? Grub4dos detects 9729*255*63*512=80,023,749,120 (roughly 80 Gb) The BIOS is limited seemingly to 1023*255*63/512=8,414,461,440 i.e. the last CHS limit of around 8 Gb The check before the remapping: checkrange 0x80 read 0x8280 && map (hd0) (hd1) checkrange 0x80 read 0x8280 && map (hd1) (hd0) map --hook Is to avoid the remapping if - fr any reason - the (Hd like) USB device is not mapped as first disk (this might happen in, say, 1% of cases or less), the device one boots form is first device in (still say) 99% of cases. Removing the check: map (hd0) (hd1) map (hd1) (hd0) map --hook is valid for this (fictional) 99% of the cases but it will fail in the remaining 1%. The suggested "manual command": is not "strictly needed" (it is only a good habit to "establish root and verify the filesystem is accessible" before actually booting from it),it makes a lot of sense if you later chainload the bootsector of that filesystem: chainloader (hd0,0)+1 since root has already been established, you can replace the above with: chainloader +1 From the result of the test it seems like the drive is mapped correctly (as drive 80), but something is "wrong" with establishing (or mantaining) current root. There should be - in theory - no need to establish a root to a volume if affterwards you chainload the MBR of the device (and not the PBR/bootsector of the volume). What happens is probably that the: rootnoverify (hd0,0) BUT, using instead: root (hd0,0) should be good also, somehow "resets" the size (number of cylinders) issue. You should try again the set of commands Steve6375 suggested BUT on command line (that should be ALWAYS used when troubleshooting) to better understand which exact command provokes the posted warning. The last two commands (before the "boot" needed on command line) should all work the same: root (hd0,0) chainloader (hd0)+1 root (hd0,0) chainloader (hd0,0)+1 root (hd0,0) chainloader +1 rootnoverify (hd0,0) chainloader (hd0)+1 rootnoverify(hd0,0) chainloader (hd0,0)+1 rootnoverify(hd0,0) chainloader +1 BUT, what may happen if you remove the check (as in the set of commands I suggested for tests) AND the BIOS doesn't map the USB device as first disk (1% of the cases)? The exchange takes always place, thus the internal disk becomes second disk and the USB device becomes first one. Since you chainload the MBR of the first device (which is the USB device), then you simply loop back to the grub4dos menu. At which point you can highlight the menu entry you were trying booting press "e", edit the menu.lstremoving the two disk re-mapping lines and try booting it again. The "queer" part is that you reported that the "first" part of the booting (that also contains the same checkrange commands) does work allright, so either the mapping of the imaged to the floppy disk devices or some timing problems or the difference between first boot (I presume a cold one) and the second (a warm one) seem to play a role in the issue. jaclaz

They are incomplete, which is another thing. I suggested you to try "A" or "B", what you posted (unless I missed something ) was: I tried "A" and it doesn't work (hanging at "A20 Debug: C806 done! ...") I tried "C" and it does work. It is not "by design". And it is not even an error, it is a "Warning". If you calculate EXACTLY the size of the disk image, counting the "default" 1 head (63 sectors) of "hidden sectors" (comprising the MBR) + the EXACT size of the partition on it (respecting the head/cylinder boundaries that FDISK or more generally any MS partitioning software up to XP/2003 do respect when making the partitions) you won't have that warning. Compare with: http://reboot.pro/?showtopic=3191 http://reboot.pro/9033/ Additionally (and this somehow and very loosely "connects" to the question about the size of the image) the BIOS used by Qemu (BOCHS one) is very "picky" and will use - depending on the size of the hard disk image that you create - an "orthodox" geometry, which in your case is a n/16/63 one, unlike the one you will have on *any* common "real" hard disk, which will be a m/255/63 one (and this may create some issues). Yes, the question was aimed to understand if you could make it smaller and try mapping it to --mem and/or using memdisk for it. You can try making the image with a different geometry, try loading it to --mem or with memdisk, try replacing EMM386 with another memory manager. jaclaz

It must be a very sophisticated piece of electronics.... WHY? [1] WHY? [2] This: (with all due respect ) sounds to me a lot like: I have not even the faintest idea on how to properly setup a multiboot system with Windows98, XP and Windows 7, by pure chance I found an app that *somehow* does what I needed, thus I recoomend everyone to use this method. This simply makes no sense : WHY?[3] WHY? [4] Mind you, you have all the rights in the world (and even one more) to have your opinions and report your experiences, but when you "recommend" or say "don't do this" or "You shall not" , there should be some (possibly "sound") reasons behind these statements. jaclaz

Anyone noticed how the image: effectively inspires something new, futuristic and never seen before... You know, like: http://fineartamerica.com/featured/fifties-retro-zero-charles-ragsdale.html or: jaclaz