# Linux file contains “@^@^@^@”, how to restore?

I just finished writing a large c code, but when I save and open again the file contains strange characters: "@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@0000664^@0001750^@0001750^@0000000031"

How can I recover the file?

I have been writing this program all day. :((

## migrated from stackoverflow.comMay 19 '12 at 20:48

This question came from our site for professional and enthusiast programmers.

• You should have been using source control... – Oliver Charlesworth May 19 '12 at 20:45
• Did you by any change do something like gcc bla.c -o bla.c? – sepp2k May 19 '12 at 20:46
• Maybe there's still a swapfile? – Angry Lettuce May 19 '12 at 20:46
• thanks for answers, i don't know what happend, i just quit the vim and reopen. – flatronka May 19 '12 at 20:51
• you type file big.c - what does it say? Doesn't look good for recovery unfortunately. – Levon May 19 '12 at 21:18

This may be a long shot, but that looks suspiciously like part of a TAR file header. Possibly you at one point tried to back it up with tar, and used the same filename as the output file? The reason I suspect this, is because a TAR file header begins with:

 char filename[100];  // null padded
char mode[8]; // octal
char nuid[8]; // octal
char ngud[8];
char size[12];
...


So looking at that snippet, it fits the pattern -- file was rw-rw-r, with the owner/group ID 1000, and the size between 200 and 207 bytes (looks like that field is cut of in your cut-n-paste). The give-away is if the file has "ustar" starting at character 257. In that case, just use the tar command to try to extract from it (in a temporary directory just in case), hopefully you'll get something out of it.

• As @Levon said, you can try file source.c to see if it recognizes it as a tar file. You could do tar -tvf source.c non destructively – Rich Homolka May 20 '12 at 2:03
• There's a good chance it won't be recoverable if this is the case - tar opens its output file before it reads its input files, so the data would be gone by the time it got there :/ – bdonlan May 20 '12 at 2:34
• i don't use tar command. I copied this code from middle of the file, not the beging. – flatronka May 20 '12 at 6:04
• If you are absolutely positive you didn't do anything specific that would account for this, then chances are you have some major file system corruption (although I haven't seen this specific error before, where one file contains another file's contents). If that is the case, then I would advise backing up what you have, unmounting the filesystem, and running fsck against it before trying to rely on it any further. But I can assure you that the snippet that you posted is almost certainly from a tar backup. – Derek Pressnall May 22 '12 at 4:37

Before you exit vim type

:e! your_file_path


to attempt to load the file. This is in case you merely tried to edit the wrong file.

In another shell, scan for a your_filename.recover or file_name.swp file. If found then starting

vim -r file_name


• thanks, but it didn't work :( – flatronka May 19 '12 at 21:25

There has been few times where I have encountered these character in log files. Many people refer them as 'hole' in file, where in there is some mismatch between the actual amount of data in the file and its indicated size. As I learned from my very little research on this, this happens because of synchronization issue when more than one operation is being performed on the file at the same time or where some space space crunch has been is encountered just at the moment of writing the file on disk. refer thisand this

To summarize it there is nothing in those part of the file and these holes are rendered in different way by different text editors.

I really feel very sorry for you, as I know how it hurts to loss something on which you have given entire day(along with your beloved effort, your passion and energy), but chances are very meek that you will be able to recover them.:(

Did you do something that removed your carriage returns? I see this when I've written a bunch of output to a file and neglected to add carriage returns. Line is just too long.

• Thanks for all answer, i was finished rewriting the code. :) – flatronka May 20 '12 at 20:26

^@ is binary zero, low-values, '\0', 0x00. Best guess is that you have a zero delimited string and you are writing out the length of the char array rather than using strlen.

• He's talking about his source code, which was corrupted in some way, not output from his program. – Bob May 20 '12 at 6:52