jaclaz

Well, decisions violating the First Amendment (or similar Freedom of press or speech) are IMHO a tadbit tough to apply to people not making money (integrally or partially) through merely re-distributing pre-made content (by others). The real issue here is about "wideness" (or "selectivity") of the blocking ("by address" vs. "by content"): http://www.reuters.com/article/2013/11/29/france-streaming-idUSL5N0JE2G920131129 Which nicely brings us back to the known Megaupload case. I have personally no particular sympathy for people that makes money through violating intellectual property rights, so, if these people ONLY did that, I am perfectly fine with that court decision, the point is whether the approach will lead to block websites where this activity is only marginal and when exactly we can call it "marginal". I have (hypothesys) a site with 100 pages. 99 are my own intellectual property or self generated content or however PD or similar. 1 is something "pirated" that I share publicly. Till now the holder of the intellectual property would send me a cease and desist letter and possibly, making leverage on the Millenium Act make google remove the result of a search. The complete opposite case: 1 page is my intellectual property, 99 are "pirated" content. The court decision seems to say that since (the specific domains) are entirely or almost entirely dedicated to they must be blocked. What if the pages are 50/50? And when they are 20/80? jaclaz

logman query providers ?? http://ss64.com/nt/logman.html http://technet.microsoft.com/en-us/library/cc788030.aspx jaclaz

@Charlotte You cannot take out some info from an unrelìable source such as Neowin and then start babbling about a few "Civil Servants". Read the source article: http://torrentfreak.com/u-s-caught-pirating-military-software-pays-50-million-to-settle-131127/ The DoJ has confirmed the settlement but won't comment it. http://www.dallasnews.com/business/business-headlines/20131124-irving-software-firm-settles-suit-with-u.s.-army-for-50-million.ece Essentially the good US G.I.men agreed to pay for a given amount of licenses and then used 18 times (like in 9,000 vs. 500) the amount for which they paid. It's not a single "civil servant" (or a bunch of them) that can deploy that number of installs and/or authorize their use in critical missions. And someone (not a "civil servant") must have authorized the signing of the settlement and consequent expenditures, US$ 50 millions are not "peanuts", were not they convinced of the wrongdoing, they could well have gone to Court. This said, I wonder who (in his/her right mind) would pay US $ 5,000 for single device license for something that sounds a lot like a "ral time tracking" software, let aloneUS $ 1.35 million per license of a software on a single server, I mean how much are the software costs of (say) UPS or DHL? jaclaz

Then, most probably cp works "correctly" with sparse files, this is good. The big issue (just verified with the sectors you sent) is that the actual part I was looking for, the "Root directory" is failed/blank. The Root starts on sector 63+32+238409+238409=476913 The bunch of sectors you sent are blank from 476913 to 476977, where a .pdf file seemingly begins. This is confirmed by the ddrescue log: 0x0E8DE000=244178944->244178944/512=476912 <- here 512 bytes (1 sector is missing, but most likely it was empty being the "tail" of the 2nd FAT) 0x0E8DE200=244179456->244179456/512=476913 <- here there are errors extending for 7168 bytes, and these are VITAL 0x0E8DFE00=244186624->244186624/512=476927 <- here 512 bytes (1 sector is missing, but most likely it was empty being the "tail" of the Root Dir) 0x0E8E0000=244187136->244187136/512=476928 roughly 15 mb (0x00ECE000=15523840) from here are "good" :thumbsup: As said there are more "holes" in the log, of course besides the above, the other one that would be very, very useful is this one: Which corresponds to sector 95 The second copy of it should be on sector 238504*512=0x7475000, which is also a "hole": The other "holes" (which would anyway be better if removed) hopefully belong to single files or to sectors that would have been anyway empty. jaclaz

Good. I got the files and will try and see if I can get out of them some better "fake" sector 95. In the meantime, you could see what happens running again ddrescue (with the log file, using the same destination file, see the docs): http://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html#Introduction maybe using in addition the "reverse" switch and without the "n" one. The log you posted has seemingly some "issues", there are quite a few "holes" or "gaps" in it. By retrying with different parameters it may help in "bettering" the image, recovering some more sectors. I am also perplexed about the "type" of the image (and of the copy of the image) you made. I mean the effect of the "S" parameter is to have a sort of "sparse" file: and this -generally speaking - while saving the space occupied by the image, makes it "non-copy", i.e. the copy will be expanded. How big (in bytes) is the "clean_disk_image.bin"? (filesize and size on disk) And is the copy you made of it the SAME size? jaclaz

I had seriously mis-read/mis-understood the issue. If the problem is "cannot login to Windows XP", possibly one of the simpler approaches is logging in without password (and then create a new "normal" account), and hopefully a simple way is to use a USB stick with PassPass (yeah, it's a "plug"" ): http://www.msfn.org/board/topic/163190-passpass-bypass-the-password/ http://www.sherlock.reboot.pro/passpass-bypass-the-password/ jaclaz

I was thinking more at this one : jaclaz

the NON-written part: .... it merely fixes the stupidity of previous update 2670838, any normal person would have made a new update, replacing the old, flaky one and including this fix, or at least put a link to KB2834140 on the actual KB2670838, but we are MS and know better.... jaclaz

267038 or 2670838? http://support.microsoft.com/kb/2670838/en-us The list of non compatible laptops is impressive. But maybe it is just a matter of installing a suitable video driver? 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