1

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. :((

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

5 Answers 5

8

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.

4
  • 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 May 20, 2012 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, 2012 at 2:34
  • i don't use tar command. I copied this code from middle of the file, not the beging.
    – flatronka
    May 20, 2012 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. May 22, 2012 at 4:37
2

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

should get your file back.

0
1

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.:(

0
0

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.

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

^@ 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.

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .