jaclaz

A perfectly "mechanically sound" AND new (and never "fixed" - BTW along an UNdocumented, UNofficial, UNsupported, casually discovered/leaked method) hard disk may fail tomorrow (or the day after tomorrow) or even NOW, for NO apparent reason. Hard disk failures are UNpredictable. There are chances that the same two hard disks (model, make, manufactured the same day, with just one single digit of the serial number increased, bought the same day in the same shop) used by two twin brothers in two identical PC's, physically located in the same, room, powered by the same line, with exactly the same contents and read/wrote in exactly the same way fail - respectively - after 1 week and after 3 years (or one or both never fail in their usage lifetime). Seriously, I have seen identical drives in identical RAIDs fail for no reason, and no, it wasnt the case about which tray (upper, lower, one of the middle ones) they were in. I would make a tested PE of some kind or a Linux Live (please read as "emergency way out") before that. Not to put you down in any way mind you, I actually tend to be an optimist , only trying to make you fully aware of the possibilities... Your playing against the odds is a lot like "playing against the house", it will win. (in the long run) But, on, the other hand: jaclaz

Naaah , the original price was $599 allright, but it was made by $500 + 99 of the cover , and they are not going to actually charge you $120 if you change your idea, only $119.99. Seriously, sometimes I do wonder how such senseless prices as the *9.00 or *9.99 are still in use (not only by Microsoft) it's not anymore the 19th century.... http://en.wikipedia.org/wiki/Psychological_pricing On other news (but still numerology related ), ever heard of anyone announcing a release on the 26th of October or anyone inviting to an UNdisclosed product announcement on October 23rd? http://www.mirror.co.uk/news/technology-science/technology/ipad-mini-release-date-price-1384082 jaclaz

Good, this is the "right" approach. There is no need whatever for a computer science degree, as a matter of fact I have personally met "IT specialists" that deemed tasks similar to this one "impossible", yet *somehow* they were later proved to be perfectly possible . In your case the issue is that there is no way to know ab initio IF it is possible or if the result, if possible, would be satisfactory. I see it more a matter of evaluating the costs/benefits of such a task, after all it is an Excel spreadsheet of which - at least from the directory structure I saw - you seemingly have earlier versions (and I presume that a copy of such earlier version is still avaialble "somewhere" - like in your home or office PC) so you have to evaluate: the time that will take you to re-update the spreadsheet (from an earlier version) the time that it would take you to re-create it from scratch the time that it would take you to learn how to (hopefully) recover that file the time that it will take you to actually analyze and (hopefully) recover that file the value you atttribute to your time (and thus the price that you may be wanting to pay a profesional for it) Of course I cannot make an "online course" on the matter (provided that I have the capabilities/knowledge to make one ), as said - unlike other much simpler cases seen (and often but not always solved) - through the forum, you are in a "difficult" situation with a huge number of "bifurcations", and exploring all the possible paths, with the aggravation of "not-real-time" comminication is not a viable possibility. I can give you the "basics" (of which some I already gave you) and suggest you the (hopefully) "right" "generic" approach and possibly a few links to read, but not much else. jaclaz

The "most dangerous" thing that can happen when "flashing" something is a power outage/failure, personally (and this applies also to BIOS flashing, modem/routers, etc.) I wouldn't EVEN THINK of performing a firmware flashing without having everything connected to a suitable UPS. The chances are low, but it can happen. 70% is not a "logical" request, most probably you are above 95% with a trend towards 99% BUT the whole point is the remaining 1÷5% IMHO if your data has less value than 70 US$ or so (a street price for a 500 Gb hard disk), it means that they have no value at all. Additionally, since you are going to spare that money for a backup, I am led to believe that you intend to re-use the "fixed" disk as primary and "only" data storage. In this latter case you have 100% probabilities to lose the data , the question becomes not anymore "IF", but rather "WHEN"... jaclaz

Yep, the "usual" approach (since the *need* for details on files is more "felt" in forensics and to a much lesser extent in data recovery) is to extract/make a copy of the $MFT and then parse it. If you search for "$MFT parsing" or "$MFT parser" or "NTFS parser" you will find a few (usually python) scripts, such as: http://www.integriography.com/ As well, if you are into putting something together yourself there are a few libraries around: http://www.codeproject.com/Articles/74128/NTFS-MFT-deleted-files http://www.codeproject.com/Articles/81456/An-NTFS-Parser-Lib and some AHK tool/code that can probably be "adapted" : http://www.autohotkey.com/community/viewtopic.php?f=13&t=85072 jaclaz

Well, if you follow the thread, you will see how OP standingbear is now among the happy bunnies : BTW you already "owe" us a cute happy bunny pic for the consultancy given till now . Cannot say, basically - provided that Seagate is telling the truth - later fiirmwares do not suffer from the SAME bug, but - as seen extensively - can get in the BSY issue allright nonetheless. The "fix" is basically a way to get off a BSY loop, but since we don't know why exactly the disk enters this loop (and when/how it does so) there is no way to know in advance IF it will be effective, let alone "actually fix" anything. Any disk "repaired" this way (as well as *any* disk *anytime*) may fail again (for the same or for other causes). As a "rule of thumb" it's not like that, i.e. it is not that you need a backup before attempting a (risky) operation such as a firmware update, you should have a backup ANYWAY (actually two of them, on different media and kept in two different physical locations) of any data that you value. Normally a firmware update should NOT create any data loss, but Murphy's Law is EVERYWHERE, continuously trying to prove itself true once again.... jaclaz

Read a few posts starting here : jaclaz

Sure you can post a link to the adapter you ordered , though "logically" you should have read the read-me-first, and the FGA's and the recommended guide before. The BSY state is typical of a particular issue of the earliest firmware, BUT it can happen (and sometimes be solved) also to later releases (most probably for "different reasons"), this should be clearly understandable from the read-me first, in the FOREWORD: http://www.msfn.org/board/index.php?showtopic=143880 and/or in the FGA''s (#2 actually): and/or in the recommended guide: http://www.mapleleafmountain.com/seagatebrick.html jaclaz

What is the problem with mft2csv? JFYI, the "development" thread is here (and yes, joakim is a member there besides MSFN and reboot.pro): http://www.forensicfocus.com/Forums/viewtopic/t=8010/postdays=0/postorder=asc/start=0/ but AFAICR mft2csv is a $MFT parser, you need to provide it with a $MFT (and that's where NTFS_File_Extracter may come into play): http://code.google.com/p/mft2csv/downloads/list Both are written with autoit and the source is available, but right now they should be GUI only. The actual output of mft2csv (once you "feed it" with a $MFT) contains more info that you will ever want to know, or if you prefer, your "requirements" are a "small subset" of the capabilities of that tool. Possibly a good idea would be to contact the Authors of tools like ndff or tfind: http://ndff.hotbox.ru/en/index.html http://www.deadnode.org/sw/tfind/ or other similar tools, that alredy have the "main" $MFT parsing engine. 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