I have an external drive. I had transfered some files/directories to it on another computer. I fired it up today, and I was getting input/output error on one directory on doing "ls -l".
I was not being able to cd into that directory (but the directory was being listed in "ls")
Fat 32 partition.
I did
fsck.vfat -a -v /dev/sdc5

It ran for some time, now I can cd into that directory, but it does not have any data.
Instead the parent directory has a bunch of "FSCK0008.REC" type files.

Whats going on, and how do I fix it ?

Those rec's are the data the fsck recovered. If you open them you might recognize some of it. But parsing it all and saving what you find would be a nightmare. Figure your data as toast unless you really want to scroll through each file line by line to identify your stuff. Some of it is probably binary and I don't know how you would separate that to make new files. But as far as fixing, your filesystem is fixed, and your data is well....."fixed"

Should I have attempted the repair in windows XP ?

The directory in question had (mostly) zip files.
I copied over one .REC file and renamed it to .zip, and was able to extract it ok.
"less xyz.REC" seems to display the files in the original archive for most of the .REC files, so most of the data seems ok.
Actually I dont really care about this particular lost directory, but if it had been something else I would have been like "NO NO NOOOOO".

How does one use .REC files in general ?
For instance, my FSCK0000.REC file shows up as around 6MB, yet when I do less FSCK0000.REC I get:
Archive: ./FSCK0000.REC
FSCK0000.REC lines 1-1/1 (END)

If you would have done the same using Windows XP, you would have gotten the same results with some other file names (I don't remember right now, FILE0001.chk or something like that).

Yes indeed...such outputs are what is collected from lost clusters or blocks. (Clusters which have lost their affiliation with the directory tree) The fixit program such as fsck in Linux, or chkdsk/Scandisk in DOS and Windows gathers them all and builds them into files of a certain maximum size. Since you knew that all or most of your files were zips, your odds of getting them back by just renaming them are good. But there may be some overlap, that is the rec files you have may contain a bit of one zip file, and a bit of another. renaming and examining will tell you for sure, but it looks good for getting at least some of it back in useable condition. If the directory tree was really trashed, I don't think Scandisk or chkdsk could have fixed things any better.

On a related note, do you guys know how convert a bunch of "xyz.REC" files to "xyz.zip" by some script ? Its going to be painful renaming 100+files manually.

Also, why is "less FSCK0000.REC" just giving me one liine, when the file is of 6+MB ?

Finally, here is another problem.
The coorupted directory was "foo" in parent folder.
I have the .REC files in the parent folder.
The .REC files consist of data that was originally in the directory foo.
On doing
"mv *.REC foo/." I get the error message (for all the files:
mv: cannot move `FSCK0083.REC' to a subdirectory of itself, `foo/./FSCK0083.REC'

Whats going on ?

0083.rec may BE a directory! Try to cd to it and see what happens....it may be the tattered remains of your original /foo! As for less, I think it just gives you a peek? Don't quote me there, I use it but rarely. As for the script.....why not? But how to do shell scripts I know not how just yet....but there was a day when I could deftly do one in BASIC! In DOS you would do something like [ren *.rec *.zip] and that would accomplish it.

Its not with just 0083.REC, I'm getting the error message with all the files.
On doing cd:
$cd FSCK0083.REC
bash: cd: FSCK0083.REC: Not a directory

The .REC files consist of data that was originally in the directory foo.

AH wait...it may be your syntax...........perhaps mv *.rec /foo, instead of foo/ I think.

This may come handy:

$ file FSCK0083.REC

It will tell you if the FSCK0083.REC is directory or a zip file.

less FSCK0000.REC will may show you one line because that one is tooooo long? Open the same file in some editor and do 'wrap'. You will see for yourself. The other possibility is that the file consists of spaces?

To rename, just do this:
$ rename REC zip *

though move command can also be used

(NOTE: There are several versions of rename roaming around, so may be this command will not work)

If you have damaged zip files. Then see below!

Try zip_fix. It program may recover corrupted zip archives(files) from HDD, CD, DVD and other devices.