jaclaz

My guess is that you are mixing in the same bag everything (and the kitchen sink) With the tool you used, and accordingly to your report, you did not touch the "2nd OS" volume, so each and every issue you have with that "2nd" install/OS is evidently unrelated. It is actually a very good thing that you zipped those files , as a matter of fact I always recommend to compress each and every attachment, because you send (and the board hosts) less bytes, and everyone will download less bytes, we must fight entropy and bloat, one byte at the time . You must try to make more "exact" and "complete" reports, this "double" lettering of the same volume is "news" Does this happen when you boot WHICH OS ("main" or "2nd")? (or does it happen in both)? Which drive letters do you get when running each OS? Do the following (booted in "main"): open a command prompttype in it: mountvol >mainMV.txtand press [ENTER] reboot to "2nd OS"open a command prompttype in it: mountvol >2ndMV.txtand press [ENTER]Compress the two resulting files C:\mainMV.txt and C:\2ndMV.txt into a .zip archive and attach them. You did not "run chkdsk", you either run chkdsk without parameters or with the /F parameter or with the /R parameter, and you ran it from either the "main" or "2nd" OS and you got a much more accurate report that you are not reporting exactly (details are important) and you did not specify on which volume you ran it. Now, provided that the volume on which the "main" OS is (the middle partition) gets drive letter D:\ (or change accordingly), when the 2nd OS is booted do exactly this: boot to the "2nd" OSopen a command prompttype in it chkdsk D: /F >mainCD.txtand press [ENTER]add the resulting file to the archive that you will attach. jaclaz

This is strange. I mean the autochk is connected to the *need* to run chkdsk to fix some issue (evidently of a minor kind, since that volume booted afterwards). I would run CHKDSK /F anyway on that volume, next. Yes, post the SFC log, though most probably those problems are unrelated. What we don' t really know is why exactly the tool that you attempted using to resize/move the partition crashed/stopèped. It is possible that there was a problem "before" that and that this problem caused the failure. jaclaz

Sure, very interesting report/opinions/whatever about the senselessness of the "Use the web search to find the associated program", but at least, in their perverted minds they are actually trying (stupidly and badly) to help the user. But my question was about something else. You remember the other thread about electronic waste? I did also a couple local (on the internet but local to Italy) searches because the very same day I was asked to deal with the demolition of a building which had beforehand to be cleared from some electronic waste (broken Tv's, etc.). Coincidence. Of course you cannot really "limit" your searches (unless you want to NOT find ), so I got a few results from people/firms doing this job in other places, particularly one doing these near Rome (i.e. about 300 Km from here), but I had a look at their site to understand something about "standard" arrangements, etc. Now, this is a "local" service (and all I had to do was to get rid of some 20 - twenty - old 14" crt Tv's a few telephones, a Fax machine), I have no need whatsoever for someone doing this work somewhere else. For several days afterwards, I found ads from this firm on the Forums. Now, I am pretty sure that I won't have soon any need to get rid of electronic waste in the Rome area, but I am even more sure that should it ever happen, I won't use the services of someone so §@ç#ing stupid as to actually pay money to deliver "targeted ads" to a NON-target! So what I was asking was whether - no matter if one later decides to buy (success for the ad) or to NOT buy (failure for the ad) a given product/service/whatever - in the opinion of members these "targeted" ads are actually hitting the target or missing it completely. jaclaz

The same happens in "Windows Setup from USB" (of which I am also "moderator" - though "child of a lesser God" ) so I would say that it is "Board wide". Maybe I have exceeded my overall "quota" ? I'll check my control panel (if I can find that page, I remember having seen once or twice) and report. jaclaz EDIT: P.S. That's probably it: Now, I may do with some extension to my quota (generally speaking) but most probably I found the culprit. It's likely Tripredacus he sent me a small (around 2.5 Mb) image of a CD from which he wasn't able to extract the internal [boot] image through my little batch here (shameless plug): http://reboot.pro/topic/12406-editing-iso-files/ http://reboot.pro/topic/12406-editing-iso-files/page-2#entry108486 very likely because he was running it into a stupid 7 or 8 - possibly even on a 64 bit system (besides using spaces and bangs "!" in file/folder names). I extracted it and attached the result to a reply, and that probably messed up the counter or whatever (it should have not allowed me the upload then, I guess it is one of the usual "by design" things from the good IPB guys). Will try deleting that attachment and see if situation changes. EDIT2: Confirmed: Now (on this very thread): It seems very like the good IPB guys (and/or *something* in the specific board settings) do not have a very clear idea of the difference between a "quota" and a "single file size" ...

Can I bring forward another question? Anyone has any idea on how "working" are ads (and "piloted" ads)? I mean everyday's life (needed preamble being that I never, and when I say never, I do mean never, clicked on an ad on google results): I search on google for a given product/service/firm/whatever I do not click on the "sponsored" results, but rather look at the "plain" results I look a few related pages, then go about doing some actual work later I go to the usual "places", MSFN, 911CD reboot.pro very often the ads on MSFN and reboot.pro are for products that were on the SAME page(s) I have already been toNow, if those ads had been for some other, different, similar product it would have made some (litlle) sense to me, re-pushing over and over the SAME products I have already seen is not (at least for me) particularly "productive". What do you think? jaclaz

It's good to see how you follow advice . The advice was: boot to the second OS run CHKDSK from it first thingThe "autochck" message roughly means that the NTFS filesystem was actually marked as "dirty" and it attempted autorunning CHKDSK (but failed). Now, take a deep breath. Boot to the second OS. From it, run CHKDSK on the "original" OS volume. Run it in three stages (let's say that when booted to the second OS the "original" OS volume is drive letter D:: CHKDSK D: CHKDSK D: /F CHKDSK D: /RChange drive letter accordingly to your settings if needed. When you run the CHKDSK D: without parameters it should tell you that it found errors but that it could not repair them because parameter /F was not specified. Post any error different from the above. jaclaz

Yes and no. Meaning that with 99% of probabilities, since you can see your files in the "simulated" partition scheme that TESTDISK found, it should mean that the filesystem is OK, i.e. it is very probable that the tool you attempted using to shrink/resize the partition simply wrote the current (wrong) entry in the partition table and failed/crashed/exited without modifying the filesystem . But it is well possible that the filesystem suffered from some damage . Until you do not write the "good" partition table and reboot, you can copy files manually (through the TESTDISK interface) "as they are". Once you reboot there are two possibilities: the volume is marked for an automatic CHKDSK ("dirty" flag) the volume is NOT marked for an automatic CHKDSKIn any case, as said, running a CHKDSK is strongly encouraged as first thing. Now, when you run CHKDSK without knowing if there is a damage in the filesytem (or the extents of this damage) you cannot know in advance what will happen. If there are no damages, then there won't be any problem. If the damage are small/trifling or however "repairable", again there won't be any problem. If the damage is serious, there is a concrete chance that CHKDSK won't be able to fully repair the volume and the process of running CHKDSK may even make a given file not recoverable anymore. And we are back to the general advice of always imaging a disk that presented issues, so that you can "go back" and try something else if what you are doing failed. As said, I do understand why you are not able to do that, but from there to make me say "Ah, well then it's OK, no need to image the disk, just write the partition table and everything will be OK" there is quite a largish leap. Most probably there are no damages to the filesystem or they are fixable by CHKDSK (and there won't be any issues even when attempting booting form that volume), but you won't manage to make me tell you "Go ahead, no prob whatsoever", as YMMGV. jaclaz

Good. Everything seems fine then, maybe excepted to the meaning of life of the verbs "to round" and to "approximate". And in any case that is the answer to the ultimate question about life, the universe an everything, not about the meaning of liff of life, which it's nothing much special: http://www.imdb.com/title/tt0085959/quotes?item=qt0256724 @dencorso What I see below Attach Files And NO I am not even THINKING of trying the advanced uploader (what i call "retarded flash based bloat" ) jaclaz

Or go forward to Opera .... jaclaz

Good . It seems a "plain" MBR partition table corruption error. This is what your disk looks like: And this is how it should look (according to TESTDISK): The first and last partitions appear the same (and correct). The one in the middle does not. If by accessing it through TESTDISK with the "simulated written" new partition table you can actually see it's contents (directories/files) it should mean that the whatever you used to resize the "middle" partition did not do it's job or was interrupted before updating the partition table. The partitioning that TESTDISK found appears correct. Now, it's up to you. You can decide to first save the data (only the really meaningful one, i.e. something that you really-really cannot replace/reinstall/recreate) by copying the files from the disk through the TESTDISK (temporary/volatile) access through the "p" (of course these files need to be copied to another disk drive) manually. And after re-run testdisk (append to the log, just in case) and repeat the analysis then write the changes: http://www.cgsecurity.org/wiki/TestDisk_Step_By_Step#Partition_table_recovery Or directly do the writing of the correct partition table. In any case, the first thing that will be needed, after the new partition table is written and a reboot, would be a CHKDSK on the volume. BUT there is something "queer" (that needs to be cleared) BEFORE doing anything of the above. You reported: What you will have after writing the partition table will be: 100 Mb System partition Primary (like you have now) 204800x512=104857600 400 Gb partition Primary 795205632x512=407145283584 100 Gb partition Primary 204800000x512=104857600000 that would be the same as you had before even attempting to shrink the middle partition. even if the "roughly" 100 Gb last partition corresponds to the 90 Gb one you saw, the math doesn't sound right, 14+300+50, even roughly, does not match the current 400 Gb (which instead sounds right). The last partition is 104,857,600,000, i.e. around 100 or 98 Gb (depending on how it is measured) In the "current" setup the "gap" between first and second partition is 15,028,191,232 bytes (which would correspond to the 14 Gb you saw), the "middle" (wrong) partition is 339,688,292,352 (which would be seen as a 316 or 324 Gb partition) and the "gap" before the last partition is 52,428,800,000, i.e. seen as 50 Gb. Is it possible that you reported 300 instead of 316 or 324? Compare with the table: jaclaz Heck the table cannot be attached, find it here: http://www2.zshares.net/lu50vdy9cz84

Let me think: how many years since I don't use anymore any Norton crap ? (actually Symantec, when Peter Norton was still around the products were very good IMHO) 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, HECK! (I need to take my left shoe off ), 11, 12, yeah, that's it more or less. And never seen any actual reason to use one since . jaclaz

I do understand that, but I have to tell you the reason why it was suggested and the risk that you may face by being not able to follow that advice. So, next step is to get and run TESTDISK, to have hopefully a general idea of the issue. You want to create a LOG and to post it as an attachment to your next reply. http://www.cgsecurity.org/wiki/TestDisk http://www.cgsecurity.org/wiki/TestDisk_Step_By_Step When asked if you want to look for partitions created under Vista, answer Yes. DO NOT, and I mean DO NOT take any action unless you are VERY, VERY sure about what you are doing before having posted the LOG and having got a reply with possible diagnosis/set of recovery instructions. jaclaz

The point is that right now you have provided some symptoms only. We need to make a diagnosis instead to say what may happen (with any degree of accuracy). It is well possible that by just correcting a bunch of bytes you can restore the volume exactly as it was or it is possible that you cannot recover any data of any kind . We have to understand what happened first thing. The point of copying the data to another disk is - besides good practice and "common sense" - in this particular case that of making sure that no TRIM or actually "garbage collection" happens. The generic risk when doing data recovery (no matter if on a SSD or an hard disk) is that attempting a given approach, this approach may make a subsequent different approach impossible (or not working, while it may have worked if the earlier attempt was not made), having a "forensic sound" image allows one to be able to re-start form scratch at will. jaclaz

Which "other" OS? First thing you should do, in any case, is to make a "forensic sound" or "dd-like" image of the disk (you will need a slightly larger disk) or make a "clone" (you will need a "same size" disk. If the "other OS" (or the PE/liveCD/whatever) you are going to boot does not send automagically the TRIM command, there should be no differences (I believe that the OCZ has not an "automatic garbage collector", but even if it has, it should be about "deleted" files and not about a partiion that became RAW) from a "normal" hard disk recovery. jaclaz

On this, I beg to disagree. IF we had a valid connection bus, fast enough and "standard" (and I mean really standard), the "real" way to be ecological, save money, re-use devices, have them portable and what not, would be a new generation of PC's made basically of just a PSU, a processor, some storage. To this you add a bus (as sad really universal) on which you plug each and every other device/component, including RAM. There has been an only seemingly unrelated smart approach for issues with video drivers in PE's, use a USB video card and have the build pre-configured for that video card drivers. And - just as an example - there is a NVDA enabled PE (NVDA is a special "screen reading software" for the visually impaired) that uses this approach. Since typically to setup an audio card (and it's drivers) requires settings/user intervention, the idea was to make the build pre-configured for a USB headset , so that the user can use it : http://reboot.pro/topic/15080-live-repair-disk-for-blind-people/ jaclaz

No. You take an UNtouched Windows 2K, DO NOT modify ANYTHING exception made for manually slipstreaming SP4, (and the 48 bit LBA key) test the install, and then you can say that. What I mean is that is possible that the HFSLIP (and/or the n mods you made to the install disc/source) may have caused a side effect that only shows on your particular machine (no offence whatever intended to you, HFSLIP or it's Author's, of course, but a bug/mistake is always a possibility). jaclaz

Maybe it is just a corrupted file. In any case it does open in 7-zip (enough to see it's contents, and there are just a Win2K and a WinXP folders, not really much of use, even if it was not corrupted and/or protected/whatever). That file is seemingly a driver for the Sager NP2885 and can be found here (directly on the support page): http://www.sagernotebook.com/index.php?page=driver_download http://www.sagernotebook.com/index.php?page=driver_download2# http://www2.sagernotebook.com/pages/notebooks/download.cfm?ProductType=2885 jaclaz

@juzzie About the Mini-XP it greatly depends on how much "mini" you want it. See this: http://minixp.reboot.pro/docs/files/index.html and the old thread starting from around here: http://reboot.pro/topic/3717-xpsp1-with-full-commandline-and-ntfs-below-10-mb/?p=152819 I personally tend to read "mini" as "micro", wimb reads it as "midi", most probably the MiniXP and/or the XPCLI projects are actually "too reduced" for your uses, and wimb's mini midi compact XP is the "right size": http://www.911cd.net/forums//index.php?s=&showtopic=23553&view=findpost&p=171411 make sure to get the latest version of the tool, it is "cumulative", right now it should be IMG_XP_78 jaclaz

Yes. http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/questions-with-yes-or-no-answers.html In your own (cited) words: JFYI, if there is someone on this board that knows where his towel is regarding Vista and specifically it's possible performance enhancements, that person is MagicAndre1981 , be aware that you are currently riscking to slip on a chocolate covered banana : http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/put-down-the-chocolate-covered-banana.html jaclaz

@Jayman JFYI (re: by design): http://reboot.pro/topic/3541-how-many-microsoft-programmers-does-it-take-to-screw-in-a-light-bulb/ jaclaz

Essentially: That kb must have been written by the people that became developers of Windows 8. jaclaz

But that is a valid alternative theory/way of operation , it doesn't matter whether right or wrong, the point is whether the one or the other is more dangerous/causes the most problems. Among the reasons why NOT having the Windows system on C: is advised (by me) and the approach I personally use are: a whole range of badly coded programs and/or malware may have the C: hard coded and operate on system files on C: a whole range of badly coded programs and/or malware may delete the MBR partition table or the whole MBR (and having the system on a volume inside extended makes it much more easy to restore it. on a multiboot system I have the "same" partition/volume with the "same" drive letter no matter the OS in which I am bootedHaving the currently booted OS always as C: and the data partition always as a "fixed, high" drive letter is a good strategy when multibooting, but limited to the "data" partitions volumes. Usually the people using this approach also "hide" other partitions in normal operation, which also may be a good choice. If you multiboot between DOS and a Windows NT system is more than enough. When you start multibooting between, say Windows 9x and more than one NT based system, it starts to be a complication, and in any case normally in this kind of setup if you want to copy a file from the Windows NT partition to the DOS one, you have to copy it to the "data" partition, then reboot and "take it" from there or you need to (temporarily) unhide the DOS partition to write directly to it, and when you have more than one instance of the same NT based OS, sometimes (if all of them use C: ) it can be difficult (or prone to errors) to remember which system you are booted in (at least for me this has been an issue). But of course everyone is perfectly free to choose the setup that he/she likes the better. jaclaz

No. Windows NT (and all NT based systems) were designed to NOT reside on C:. One of the innovations was that the C: "remained" the active primary partition (for DOS and other real mode OS) and that Windows NT could be installed in a logical volume inside extended partition. Since NT 3.51 times (that is 1993, i.e. 20 - twenty - years ago) I never had any of my systems have C: as the windows NT system drive letter, and I always installed any flavour of the NT faily inside a volume inside extended. There is NO actual issue with any NT based system NOT being at C:, the issue is installing to C: and later change the drive letter associated to that volume. @aurgathor Really, it is not something that makes sense to change drive lettering of a system. However, basically, you need to: change the bootmgr drive lettering <- this is specific to Vista and later and may not be needed, it would probably be better to re-build a \boot\BCD from scratch change the Dosdevices drive lettering in the Registry change each and every reference in the Registry to C:\ to (say) E: (or whatever letter)In the good ol' times of 2K, I would make a copy of the whole "system" drive (an additional volume, made by shrinking the current system volume and creating a new one, to which each and every file is copied, while the system is offline, like through a further install or a PE), and have it mounted as (say) E:, then I would exchange in MountedDevices C: with E:, then I would run COA2 on the Registry changing all references from C:\ to E:\. The second copy is because for some time during the operations the Windows may run "partly on C: and partly on E:". Then I would have checked everything twice or thrice, reboot, make the "new copy" hidden and with crossed fingers, hope that everything worked. With a "freshly installed" system it worked alright, never thought to do that on a "old, used a lot, with a zillion apps installed" one. With Windows 7 I would expect all kind of issues with permissions, UAC, privileges, and something more. jaclaz

May I add "unsurprisingly"? jaclaz

Which is bad , both because of the non-detection and because you posted in the wrong place, yours is a 7200.4. Is there a difficult part in "7200.11" that confused you? Which is bad , both because it didn't work and because it means you did not take some time to research before attempting it. Hardly surprising. Maybe this hints that you weren't capable (no offence intended ) to properly swap them. The probability of someone that attempts a PCB SWAP to be capable of doing a platter swap are so low that the Heart of Gold Improbability Drive could run a couple years on that math. If ALSO the "donor" disk, once re-transplanted it's original parts is not working anymore it means that your procedure is incorrect or that you have not the suitable tools or both. Maybe had you read BEFORE the READ-ME-FIRST: http://www.msfn.org/board/topic/143880-seagate-barracuda-720011-read-me-first/ and the FGA's: http://www.msfn.org/board/topic/147532-fga-for-the-seagate-720011-drives/ You would have already learned that: a BSY or LBA0 has to be diagnosedthis thread is for the 7200.11 ONLYthat a PCB SWAP won't workthat even THINKING of doing a platter swap will ruin the drive for goodthat even IF the commands for the 7200.4 were known, the idea is to fiddle with the RS232/TTL thingy and attempt diagnosing the issue BEFORE disassembling a disk drive.What isn't written there is that besides a platter exchange being one of the most difficult things to perform (in controlled environment only) when it comes to multi-platter disk is a nearly impossible task for a non-professional without all the needed tools, but more than that without the specific experience and knowledge. Unless I am mistaken that disk has two platters. The diagnosis of your disk is thus currently: no matter what was the original cause of failure, you have now a disk with platters that may be contaminated but that are SURELY misaligned .Of the several professional data recovery companies out there, only a few are actually capable (and have the tools) to do a platter swap on a multi-platter drive, and none or next to none will be able to re-align two platters. I could name you two firms, i365 (which is Seagate's own data recovery firm) and Kroll Ontrack that may be able to do that. We are talking anyway of something that IF possible at all, will be in the several (many) hundred dollars, possibly thousands. Sorry being a bearer of bad news, but your chances with DIY are 0 (zero) and possibly even for a professional they are very near to that. jaclaz