Hi! I used testdisk to rebuild my volume's FS but now many files are corrupt e.g. iso's and archives. Although they open as usual e.g. mounting, extracting they seem all fine but then the resulting data is corrupt e.g. I/O errors when executing binaries, files are missing etc. Before yesterday I tried to sync/upload files from the volume and the sync app was returning unreadable characters like so : I have tried using dosfck to check/repair the filesystem and it takes unusually too long and outputs full of unreadable characters similar to above. I don't know what is the nature of the problem but when I used Testdisk to rebuild the filesystem of the truecrypt volume everything seemed flawless; hence I've only realized there's a problem after a couple of days using the volume when after I noticed packages were mostly corrupt e.g. sfs, iso, tar, exe packages' md5/sha checksums don't match. Following is other information preceding Testdisk's use which is very simple really and precise: Looking back further, what led me to come to event of rebuilding the FS with Testdisk is that I was messing around with my HDD's partition table e.g. reorganising partitions and restoring MBR backups severally. All the while my volume and data was still completely intact. Then at one point, one day, I don't know whether it was my that MBR was faulty or a program called fdisk just was freaking out but following is exactly what I did and/or occurred: Lets set a few things straight first: All the times that I altered the HDD's PT like I've explained above, I always made sure the turecrypt partition was always primary and with the same number '1'(as it was initially the first one). Apart from restoring the MBR and the method being the explicit bit by bit style, I at all times except one I only used the program Testdisk for partitioning. I created an extended partition filling the entire HDD then made my volume the first partition there. This differed from the partition's initial configuration in partition number and type of 'logical' than 'primary'. Then I restored an MBR backup. After that, Fdisk started giving errors when trying to create a new 'dos' partition table, so that is when I then used Gparted to create a new ms-dos partition table and then after that mounting the volume in truecrypt would give me: “Error mounting...NTFS signature is missing. Failed to mount '/dev/sda1': Invalid argument The device '/dev/sda1' doesn't seem to have a valid NTFS. Maybe the wrong device is used? Or the whole disk instead of a partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?” I don't know whether the problem maybe incapability of the Testdisk program but another thing in the sequence of events is that just before using testdisk, I tried using fdisk to partition the volume when '...NTFS signature is missing' error but then I coudn't be able to mount it since it was showing as /dev/loop1/p1, */p1 or something. Right now at least I am able to use my Word documents, pictures, text files and a couple other data, though I'm not sure it's a good idea to mount it not as read-only. I have so much valuable data stored on the volume not to mention newly added data hasn't been backup from about 18 weeks, and worst thing is that the data stored in the volume is needed for day to day use and the backup drive is broken so no mirror to work from. Thanks in advance for any help or advice.
Development: What's important is to know what's the nature of the problem. Since the truecrypt volume stopped mounting precisely after overwritting the partition table with an extended partition spanning the entire drive as explained above, what component of the truecrypt volume's data might have been overwritten? And if that is the cause, could I overwrite the first few hundreds of bytes with a previous raw backup of the volume?
On modern storage devices a GUID Partition Table is written holding at least an EFI Systems Partition (usually /dev/sda1) mounted by the EFI firmware of your computer and an additional typical OS partition holding the OS and your personal data. I would no longer try encrypting whole disk / partition (as that doesn't really bring you any security benefits anymore due to that fact that your personal data is spied up on from within the OS which has access to all your files after you unlock the encrypted whole disk / partition). I would guess that opening up whole disk OS main partition (NTFS / EXT4 on MS / Linux) the encryption layer sits in between the OS and the FileSystem driver. If that layer ever gets removed or overruled by testdisk / checkdisk / fsck etc. making mandatory correction then (possible) encryption flags on reserved GPT areas gets corrected or another Live OS is loaded (not having the encryption layer in between) making mandatory corrections to the GPT (ensuring the CRC's match up again) then you're screwed. Don't use whole disk encryption!!! Only use file encryption for these reasons. My guess is that testdisk got direct access to your OS main partition ignoring the encryption flags and making corrections and screwing up your encryption flags. Something like that. For me there are a couple of simple rules that say keep your personal data / documents completely separate from your OS and keep them as encrypted files (strongest encryption possible: OTP) so you can restore them OS independent and even backup them to the cloud and any regular USB stick safe and sound.
