From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.62) (envelope-from ) id 1Hp3mE-0001Wi-JK for garchives@archives.gentoo.org; Fri, 18 May 2007 14:49:55 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.0/8.14.0) with SMTP id l4IEmdBf023024; Fri, 18 May 2007 14:48:39 GMT Received: from dcnode-02.unlimitedmail.net (139.Red-80-26-111.staticIP.rima-tde.net [80.26.111.139]) by robin.gentoo.org (8.14.0/8.14.0) with ESMTP id l4IEiG24018106 for ; Fri, 18 May 2007 14:44:16 GMT Received: from ppp.zz ([137.204.208.98]) (authenticated bits=0) by dcnode-02.unlimitedmail.net (8.14.0/8.14.0) with ESMTP id l4IEi9V5027785 for ; Fri, 18 May 2007 16:44:10 +0200 From: Etaoin Shrdlu To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Corrupt USB pen drive Date: Fri, 18 May 2007 17:16:42 +0200 User-Agent: KMail/1.9.5 References: <200705171236.28695.michaelkintzios@gmail.com> <20070518142540.4bf077f2.hilse@web.de> <200705181411.23476.michaelkintzios@gmail.com> In-Reply-To: <200705181411.23476.michaelkintzios@gmail.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200705181716.42536.shrdlu@unlimitedmail.org> X-UnlimitedMail-MailScanner-From: shrdlu@unlimitedmail.org X-Spam-Status: No X-Archives-Salt: bb5863f8-1af9-4fea-97d4-41f591fe992f X-Archives-Hash: dbee7e0d41c37563edc7a8559d1bb707 On Friday 18 May 2007 15:11, Mick wrote: > On Friday 18 May 2007 13:25, Hans-Werner Hilse wrote: > > Did you try the recovery tools for the FS in question? > > I tried fsck.msdos but didn't fix it. > > Like most USB sticks I would assume that it is either FAT32 or FAT16. > Given that this is what I see when I dump the first few bytes, can you > please tell me where the fs data starts and how to dd that without inc > the initial partition table data? > ============================================== > 000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > * > 0001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa > 000200 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > * > 020000 01 df 02 df 03 df 04 df 05 df 06 df 07 df 08 df > >[cut] > I assume that the asterisks indicate a new file starting there? Are you using hexdump to read the data? Does the above output come from hexdumping the actual device or the image file? The asterisks look strange. If you look carefully, you see that each asterisk does not merely replace a single line of output, but several lines. Look at the addresses of the lines before and after: for example, 000200 -> asterisk -> 020000 in your output above. So, that asterisk represents 0x020000 - 0x000210 = 0x1fdf0 bytes, ie 130544 bytes. If the dump comes from the actual device (like I suppose), it could be that these bytes are skipped because they are somehow unreadable, so it's really difficult to compare this output with one from a working device, in either HD or superfloppy mode. In particular, there is an asterisk immediately after the first 16 bytes (line 000000), and the dump continues at byte 0x0001f0 (496 decimal), and this means that the very first sector (where the interesting stuff is) is almost entirely damaged or otherwise unreadable. Also, trying to dd the device to a file as you did would almost certainly insert unpredictable garbage in the file to represent the unreadable parts of the device. Chances are it was in HD mode (ie, with a partition table), because the signature at the end of the first 512 bytes (the "55 aa" at the end of the 0001f0 line) indicates a boot sector (the MBR). Within this boot sector, the partition table is 64 bytes long and usually lives from byte 446 to byte 509 of the sector (512 bytes long, numbered from 0 to 511; bytes 510 and 511 are the signature). Since a partition table is composed of four records, each 16 bytes long, this means you have only the last 14 bytes of the fourth partition table record. But, it's very very likely that there was only a single partition, and thus the fourth record is unused and set to all zeros. What you would need is the value of the bytes from 446 to 461 (the first partition table record, which has info about the first partition), but, as I said above, all this data seems to be lost in the asterisk, like tears in the rain (cit.). Bottom line: I would not bet on data recovery from that stick. It's also true that there might be some program I'm unaware of which could try or be able to recover things, but unfortunately I have no advice for you about this. -- gentoo-user@gentoo.org mailing list