jaclaz

For NO apparent reason. jaclaz

Just for the record, the previous post was NOT a fix, nor a solution, and not even an attempt to a fix, it was "asking for more info as I was not sure about your question". A possible solution may be to disable the Adobe update and run manually (through your own Task, let's say once daily) the Flash update through command line, *like*: http://forums.adobe.com/thread/1052745 http://www.karlhorky.com/2012/06/manually-run-autoupdate-for-adobe-flash.html I am taking however note of how graciously you answered to such request for further info, and will surely refrain from further posting anything that may appear to you as a solution but that is not. jaclaz

Pardon me, but I am not sure to understand the issue , can you not disable the updates? Like: http://forums.adobe.com/thread/1250949 and/or: http://helpx.adobe.com/flash-player/kb/administration-configure-auto-update-notification.html http://www.dedoimedo.com/computers/flash-update-settings.html jaclaz

WHY dit it take so long? http://www.msfn.org/board/topic/163682-fast-install/ jaclaz

Unrelated, but not much, the local geniuses that are carrying on the "digital revolution" for the Public sector in Italy, a company called SOGEI, that holds the datacenters for most Public Administartion services (including tax paying ) has had their server farms go down (badly and abruptly). The company CEO was in the Parliament for several hours no more than two weeks ago explaining how good and cool they were, how brilliant was the idea of having all the data of all State Administrations managed by them in a server farm (of which supposedly a 1:1 mirror exists), how reliable was the system they had put up (they even had thought of electricity issues and they had diesel powered emergency electric generators. I mean, WOW! ). Facts are that the "main" shut down abruptly two days ago and the almost total data blackout lasted a whole day (Italian): http://www.corrierecomunicazioni.it/pa-digitale/24529_sogei-torna-a-funzionare-il-sistema-informativo-della-fiscalita.htm Obviously the "mirror" completely failed to work. And yes, Rick Harris should not have done that. jaclaz

Yep , but you see, everything is "relative". Having a partition aligned to 64K as a multiple of 4096 bytes (the common cluster size in NTFS) is an advantage where the BUS (i.e. SATA2 or later) is faster than the actual hard disk. BTW this alignment favours only some types of data access, compare with: http://reboot.pro/topic/9897-vistawin7-versus-xp-partitioning-issue/?p=85960 and it applies (mainly) to NTFS (as NTFS is "inherently" aligned to cluster size), it won't work (unless some further measures are taken) to FAT/FAT32, see: http://www.msfn.org/board/topic/151798-does-fat32-align-its-clusters/ http://reboot.pro/topic/16775-discover-allocation-unit-and-other-information-of-ufd-under-windows/ http://reboot.pro/topic/16783-rmprepusb-faster-fat32-write-access-on-flash-memory-drives/ It may also apply to EXT2/3/4 , but the point is that if the bus is slower than the device (such as it would be in a NAS) there won't likely be any positive effect. What people sometimes forget is that only relatively recently actually hard disks were capable of saturating a SATA1 (or ATA6, i.e. IDE133) bus speeds. A SATA2 bus outperforms *any* harddisk, the new frontier (SSD's) are faster and do *need* SATA3, but when you put in it a slowish intermediate (such as USB2 or Ethernet connection) the performance of the bus is so inferior to that of the device that it makes little sense to optimize the device. jaclaz

Here: http://www.msfn.org/board/topic/128807-the-solution-for-seagate-720011-hdds/page-160#entry984522 http://www.msfn.org/board/topic/128807-the-solution-for-seagate-720011-hdds/page-173#entry1014506 http://www.pololu.com/catalog/product/126 http://www.pololu.com/docs/0J16 and as Note1 to the Guide by CarterinCanada: http://www.mapleleafmountain.com/seagatebrick.html @Confused07 Usually the good guys @ Onepcbsolutions are very nice, and I am pretty sure that they can do the ROM swap for you alright, the point is however IF this will be effective. What I mean if since you have this "intermittent" issue, it could be caused both by an actual hardware problem (that would be resolved by the "new" PCB with the transferred ROM) or if - for any reason - the firmware has entered into some kind of loop (different form the "usual" one) in which case it may not work. Anyway, since what you risk (the 50 bucks) is much less than what you would have to pay for a dignosis by a recovery pro, it is still IMHO worth an attempt. jaclaz

I am not much familiar with the licensing options of DMDE, but both Home and Express would do (if needed) in your case: http://dmde.com/editions.html the difference is support period (that you probably - or hopefully - won't need at all) and number of hardware changes per year (that again you should not need at all). This is "personal use only", right? There is no need to "realign" anything (connected to using a 32 bit OS), maybe if the NAS uses Ext2/3/4 there is a need to re-format as NTFS (there are Ext2/3 drivers for Windows XP, but cannot say if they are reliable with this mass of data/size of file/transfer). You can mount a HD "temporarily" alright, I mean you open the side of the case, put the harddisk on a piece of cardboard beside the case or on top of it and have the cables get out of the case. As long as you don't have kids or pets at loose in the house there would be no issues. It is some time since I image such a huge hard disk, but it should be (at top SATA 2 speed) something like 150 Mb/s top speed, but on average more like 100 Mb/s, i.e. you have around 2 Tb=2,000 Gb=2,000,000 Mb divided by 100, 2,000,000/100=20,000 seconds/3600=5,55 hours, likely it will take something between 5 and 8 hours. A "normal" 100 Mbps local Lan will have at the most 12.5 Mb/s of transfer, more probably 10 Mb/s, i.e. it will take approximately ten times! Think at all the things that may go wrong (power outage/blackout as an example) over 5 days 24h. jaclaz

Ok, all data seems (if not "right") understandable. I am still curious about the exact procedure that was originally used to create the filesystem. The $MFT is on cluster #3, which is VERY unusual (default is as said 786432), most probably this is the single issue that "throws off" TESTDISK. The data seems like entirely recoverable. : The point is whether once you will have made a simple corrections to the MBR and possibly checked the Bootsector mirror (or replace it) it will be possible only through DMDE (in which case you will need to buy a license for the full version, since the Free one only allows for recovery of single items) or the small manual repairs will be enough to run TESTDISK and get the files or (better) it will be possible to run successfully CHKDSK. If you have found a suitable way to make the image (always better safe than sorry) all seems like fine and dandy. The plan is to have the image created, do a few changes/correction on the disk and let CHKDSK fix the rest, if it works (it seemingly worked nicely on the partially rebuilt filesystem I tried ), good, if it doesn't, we restore the image and try again with DMDE. In the meantime I will rebuild another partial filesystem from scratch and see what TESTDISK can do with it. jaclaz P.S.: you might want to remove/delete the last file you uploaded to zshare

So, when you finally found this thread you did not read the last page (this one) and did not read the first page, just one page here and one there. If you check it, the first post on it has: Please make sure you've READ the Read-Me-First Sticky FIRST! in large, friendly letters , BIGGISH, bolded and in different colours so that the particular message is highlighted. Anyway, did the loopback test succeed? jaclaz

Sure , and since it's like almost 5 (five) years that on nearly each §@ç#ing page of this thread (including this #182 one) there is a post mentioning the Read-me-first and/or the FGA's (often by yours truly ) I am pretty sure that some (out of the many) actually read them before posting the same questions already asked and possibly this partially explains why I seem grumpier than what I normally am . More seriously, even a TTL adapter that has worked once or more than once before may become dead suddenly (as an example the new version of a "good" adapter has an added capacitor to prevent spikes that have killed tens of these particular TTL adapters in the past), and doing a loopback test is the first thing to check. jaclaz

A 2 Tb hard disk would be enough if you do a "clone" (i.e. you can write directly to a disk or \\.\Physicaldrive). A 2 Tb hard disk would NOT be enough if you do an "image" (i.e. a file written on an existing filesystem) as the filesystem structures will occupy a part of the 2 Tb. If you can use Explorer, if you select the volume and Right click->Properties you need to have at least 2,000,398,934,016 bytes in "Free Space": the above example most likely belongs to a 2Tb disk partitioned under XP that has a few hidden sectors at the beginning and some unused space at the end, since also your currently failed disk has some unused space at the end, you could do with (3,907,024,064+1)*512=2,000,396,321,280 to image/clone the WHOLE disk. BUT it would be also "enough" if you save separately (in two distinct files) only the sectors from 0 to 100 and the sectors from 16,370,000 (rounded) to 3,907,024,064, which would make (3,907,024,064+1-16,370,000)*512=1,992,014,881,280 which should fit in a filesystem on a 2 Tb disk. With DMDE, after having opened the PhysicalDrive, go to Tools->Copy Sectors myfirst100.bin: Input in "Source" Start sector=0 Number of sectors=100 In "Destination" click File button and then Save to myfirst100.binmybadpart300.bin: Input in "Source" Start sector=16370098 Number of sectors=300 In "Destination" click File button and then Save to mybadpart300.binmygoodpart300.bin: Input in "Source" Start sector=16373560 Number of sectors=300 In "Destination" click File button and then Save to mygoodpart300.binmygood$MFT300.bin: Input in "Source" Start sector=???????? Number of sectors=300 <- the ???????? stand for the LBA that I still miss In "Destination" click File button and then Save mygood$MFT300.binjaclaz

Which nicely confirms that you completely failed to READ the info available BEFORE doing crazy (or random) or BOTH attempts, you know, like this sticky here: http://www.msfn.org/board/topic/150215-dont-even-think-of-swapping-pcbs-on-720011/ or the FGA's: http://www.msfn.org/board/topic/147532-fga-for-the-seagate-720011-drives/ No, the ground has no meaning as there is only "one" device, (the PC and attached to it the TTL adapter, which being attached to it has already a common ground). The loopback test only checks for the actual "Hyperterminal to TTL and back" path working, see also here: http://www.msfn.org/board/topic/128807-the-solution-for-seagate-720011-hdds/?p=1016161 If you have a "wrong" TTL adapter (5V TTL instead of 3.3V TTL) or "wrong" settings for transmission parameters it will work as well. jaclaz

Hmmm, thankz, though.... jaclaz

I can haz extention? Pleeze..... jaclaz

NO, the upload limit (maximum global size for attachments on MSFN.ORG forum) is much lower expecially - I believe - for new members, if you sum all the screenshots and logs you posted, you have probably reached it. It does matter that you find a way to produce that screenshot, as I need to know the actual LBA of the "real", "good" $MFT (the one found for the volume that starts @16373760) and have to know what actually it is found when using that $MFT. From what I could gather till now, partition Wizard simply recreated a partition with a slightly different situation. It is possible that CHKDSK made some "damage", but I doubt it (and it shoudl have been an extremely "short" run of CHKDSK) In the meantime I thought a bit about WHAT caused the issue, and (morally only ) I have good news . It was not strictly your fault (nor the fault of the tools you used), it was one of the lesser known SERIOUS glitches with XP (actually with it's Disk Manager), see here: http://reboot.pro/topic/9897-vistawin7-versus-xp-partitioning-issue/ basically the XP disk manager CANNOT deal with disks containing logical volumes NOT aligned to cylinders and whenever you do *anything* on such a disk, even something as trifling as changing the active status of a Primary partition, it attempts to re-calculate/re-check the whole partitioning setup, fails and plainly deletes any and all logical volumes inside extended. The issues (if any) with that NAS are the following: the filesystem of the partition on which you create the huge file must be capable of making such a big file (this means either NTFS or Ext2/3/4, I am not familiar with that hardware but - if by any chance the filesystem is FAT32 it won't work ) and you need to have anyway 2,000,398,934,016 free space on the volume on which you make the file, if the actual disk in the NAS is 2Tb in size, I doubt you will have that amount of space actually free in the filesystemtransferring 2 Tb over the network might be very slow (normally such dd copies are made to disks directly connected to the machine)I am not aware of a limitation in the free edition of DMDE about the imaging, but you can use datarescuedd as well as *any* tool capable of making a dd-like copy of the disk. BEFORE you make the "huge copy" I would like to have a look at: some 100 sectors starting from sector 0: dsfo \\.\PhysicalDriven 0 51200 C:\myfirst100.bin some 300 sectors starting from sector 16370098 <- these include also the beginning of the "bad" $MFT which is @16370322 dsfo \\.\PhysicalDriven 8381490176 153600 C:\mybadpart300.bin some 300 sectors starting from sector 16373560 dsfo \\.\PhysicalDriven 8383262720 153600 C:\mygoodpart300.bin some 300 sectors starting from sector (the whatever sector the "good $MFT" is) dsfo \\.\PhysicalDriven ???????? 153600 C:\mygood$MFT300.bin (in the screenshot you posted http://www.msfn.org/board/uploads/post-384634-0-55038100-1385319889.jpg which is about the "bad" $MFT, the meaningful LBA address is the one in the top left of the right bottom pane, in GREEN LBA:16370322, I need the corresponding one for the "good" $MFT) The n in the above is the "usual" disk number. You can get the dsfo.exe as part of the DSFOK toolkit: http://members.ozemail.com.au/~nulifetv/freezip/freeware/ extract it in a directory like C:\dsfok, then open a command prompt and navigate to it and then enter the command lines above. If you have issues with command line tools, say so BEFORE attempting using them incorrectly. As an alternative you can use the DMDE or the DatarescueDD to create the needed "partial" .bin files. Once you have created them, do compress them all into a .zip archive, upload to a free hosting site and post a link to the file. Ask for clarifications if you have doubts. jaclaz

It's not like "gambling". You connect to the "right" pins. Last character in the above sentence is a full stop or period. You can try making a loopback test (do READ the Read-me-first: http://www.msfn.org/board/topic/143880-seagate-barracuda-720011-read-me-first/ ) to verify that the TTL adapter is working. You can try with the PCB fully detached from disk. if it doesn't work, it is likely that your disk is suffering form ANOTHER problem (NOT BSY, NOT LBA0) or that the board is "dead" . jaclaz

It's not "news", it's more than two years old: http://www.istartedsomething.com/20120121/cicada-3301-cryptographic-puzzle-game-played-out-on-4chan-reddit-best-job-hire-in-disguise/ http://mentalfloss.com/article/31932/chasing-cicada-exploring-darkest-corridors-internet http://uncovering-cicada.wikia.com/wiki/What_Happened_Part_1_(2013) but I don't think it has been mentioned on MSFN.ORG. jaclaz

Yep , possibly, but Windows 9 will come in a nice set of 25 Blue Rays and will need 8 Tb just for the minimum install of the OS. If you go for the downloadable version it will be like (very rough estimation): 24 hours on fibre24 days on DSL24 years on dial up jaclaz

Yes, there is a "max size" of the attachments. You can upload the screenshots to a free hosting service, like -as an example - zshare: http://www2.zshares.net/ If you compare the screenshot you posted: http://www.msfn.org/board/uploads/post-384634-0-60686200-1385318959.jpg with this snippet of the DMDE Help: and based on your previous screenshot here: http://www.msfn.org/board/uploads/post-384634-0-91885300-1385309565.jpg you will see how everything confirms that the "good" voume is the one starting on 16373760, it is possible that you (or DMDE) are doing *something* that currently prevents the correct parsing of that volume data. Maybe you should try closing and restarting DMDE, then do a new scan, starting from fresh. When you get to this screenshot: http://www.msfn.org/board/uploads/post-384634-0-91885300-1385309565.jpg if you select the "NTFS0" it should open the "right" data. It is possible that something has been modified by your previous attempts with partition wizard or by the built-in Windows tools, but I doubt it, in any case there is "enough" to attempt a filesystem based recovery. (i.e. it is worth the time to make a dd-like copy of the disk as is) In DMDE re-open the Physical disk, then go to "Tools"-> Copy Sectors, click on Partition button, on the dialog that opens click on the PhysicalDisk listing and click OK (this will auto-compile the fields Start Sector and End Sector in the "Source" part of the dialog), choose in the "Target" part a file. Be VERY careful to choose a drive with enough space! The resulting file will be a 1:1 copy of the disk, so it will be 2 Tb in size! Consider that it will take several hours to make the copy and if - for whatever reasons - either the source or the target disk tend to heat up, it would be a good idea to add something to keep them cool, like a small fan. jaclaz

@ internalsio As a side note, are you sure-sure that: Windows XP based PE's (i.e. PE 1.x) actually ever used the 3 Mb "read only disk"? (surely they didn't have BOOTMGR or the \boot\BCD) jaclaz

No, there is a misunderstanding. in this screenshot here: http://www.msfn.org/board/uploads/post-384634-0-60686200-1385318959.jpg you must try selecting the "$No Name 02" (which is the one that starts at 16373760) and click "Open Volume". jaclaz

Why would you prefer not to publish it? jaclaz

Good. So DMDE found two possible NTFS volumes: NTFS 0 which has 4412 entries in the $MFT and that supposedly starts at sector 16373760 NTFS 1 which has 5 entries in the $MFT and that supposedly starts at sector 16370298 The sector 16373760 corresponds to CHS 1019/55/61 and is correctly "Mb" aligned, as 7995*1048576/512=16373760 The sector 16370298 corresponds to CHS 1019/1/1 (which is the data currently in the MBR) and is correctly "cylinder" aligned. It seems like originally the Disk has been partitioned/formatted under an OS (or with a tool) that aligns to Mb and that (for whatever reason) the tool you used cannot recognize such partitioning scheme and defaulted to a "cylinder aligned" values. If this is the case, if in DMDE you select the NTFS0 volume and press the "Open Volume" button, and in the window that opens you click on the [+] besides "Root", you should be able to see most if not all the files you had before. If you click on "Metadata" and click on the line that starts with $AttrDef, on the right panel you should see the $MFT entry and it's creation date (see if it "sounds" like the right one for the period when the disk was originally formatted). If you double click on the $MFT entry in the right top pane, in the lower one you should see the actual LBA of the $MFT and a hex view of it. See the attached screenshot of an "example" volume. Does this happen? What do you find instead? jaclaz

Wait a minute. It is possible that originally you made a (huge) Extended partition and created two logical volumes in it? That would explain how you managed to delete BOTH volumes from XP disk Management, and also the reason why in the posted screenshot of Minitool Partition Wizard the "lost" partition is seen as "logical". What we need to find is the $MFT of the volume that you had as H:. A "normal" NTFS partition sized above 5 or 6 Gb has it's $MFT on cluster 786432 and the default cluster size for a NTFS partition of that size should be 8 sectors. So, the $MFT should not be before 786432*8=6291456 sectors starting from the beginning of the volume. Here the problem seems to be that we don't know for sure where the volume exactly began. Try the following: in HxD, go to sector 6291456 of the disk once there Search->Find "search for=FILE0 Datatype=Text-string Search direction=ForwardIt may take a long time for the search to find a hit (if any). Alternatively, as it might be faster/better, do the following: get DMDE from here: http://dmde.com/ extract it to a directory run dmde Select the PhysicalDisk 3 click on the button "NTFS search" leave the scan areas settings "start sector" at 0 change the "end sector" by using the cursor to something around 20 Gb (jolt down the exact sector number) click on Search post a screenshot of results (if any) if no results are found, re-run the search by selecting "Range", this time use as "start sector" what you had before as "end sector" and limit the "end sector" to 40 Gb if no result repeat up to 60 Gb and then up to 80 Gb (I don't think there can be anything of use beyond this range) jaclaz